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

With annotations offering no safety profile (all hints false), the description carries the full burden of behavioral disclosure. It does this thoroughly: it warns that the operation is not idempotent, explains that a timeout may still have succeeded, and advises checking before retrying to avoid duplicates. It also discloses the visibility constraint and the character limit, which are behavioral traits the schema and annotations do not express.

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 compact and front-loaded: purpose first, then constraints, then the retry warning. Every sentence carries essential information, and the non-idempotency warning is placed last where it can be recalled when handling errors. 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 small write-only tool with a defined output schema, the description is complete: it states what the note is, who sees it, the size limit, the optional context parameter, how to verify existing notes, and how to safely handle timeouts. No critical call-time behavior is left undisclosed.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful semantics beyond the schema by clarifying that leadId refers to a lead of the current team and that recordId provides optional submission context. It also restates the 2000-character cap, reinforcing the schema's maxLength constraint.

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

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

The description opens with a specific action and resource: 'Write an internal follow-up note on a lead.' It immediately distinguishes the tool from siblings by specifying visibility (team members only, never the respondent) and by naming how to read existing notes via get_lead, which separates it from read operations.

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

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

The description gives clear context for when this tool is appropriate: adding an internal note with team-only visibility, optional record context, and a max length. It explicitly points to get_lead(includeComments: true) as the way to read existing notes, but does not explicitly name exclusions or alternatives beyond that reading path, so it stops short of a full when-not-to-use guide.

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 description goes well beyond the all-false annotations by disclosing that the call is not idempotent and that retrying after a timeout can create duplicates. It also specifies that irrelevant fields are either rejected with an explanatory error or ignored, and details scene/type restrictions such as 'Rejected for DateField / TimeField / Rate' and 'scored_quiz only'.

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

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

The description is long but packed with necessary information for a 24-parameter tool, and it fronts the core purpose before enumerating types. The non-idempotency warning is placed at the end, which is slightly buried but still present; 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?

Between the tool description, the exhaustive schema-level field-applicability text, and the output schema, an agent has everything needed to call this correctly: type/scene rules, scoring semantics, field rejection behavior, and the retry caveat. Nothing critical 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%, and each parameter already carries detailed semantics (e.g., `multiple` shape, `choice` nesting, `aiMatch` grading). The tool description adds a high-level summary and a few cross-cutting notes (e.g., 'prefer DropDown past 20 choices'), but most parameter detail is redundant with 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 opens with 'Append an item to the end of a form', naming the action, resource, and position precisely. The subsequent breakdown of question types reinforces the scope, and the 'to the end' wording implicitly distinguishes it from the sibling insert_question.

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 clearly implies the tool is for appending to the end of a form, but it never explicitly contrasts it with alternatives such as insert_question for positional insertions or update_question for modifications. The extensive type/scene guidance is about parameter selection rather than tool selection, so an agent gets no explicit when-not 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses side effects: Each change is recorded on the lead's timeline, and the assignee gets one aggregated notification for the whole batch. It also explains unassign behavior and the active non-viewer member requirement, with no contradiction of annotations.

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

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

The description is four compact sentences with no filler; purpose, batching, assignee rules, and side effects each get exactly one sentence. It is front-loaded with the core action before constraints.

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

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

For a two-parameter mutation with an output schema, the description covers what, when, how, constraints, and side effects. There is no missing information an agent needs to select and invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: it frames leadIds as a batch that must be passed in one call and adds assignee validity constraints and the me/null convention. This materially improves an agent's ability to set both parameters correctly.

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

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

The description opens with a specific verb-resource pair, Assign one or more leads of the current team to a member, or clear the assignee, which also covers the unassign case. This clearly distinguishes assign_leads from siblings like update_lead, set_lead_tags, or add_lead_comment.

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

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

It gives explicit batching guidance: Pass every lead id in a single call (up to 50) — do not loop one call per lead. It also references the sibling tool for valid assignees (see list_lead_settings.assignableMembers) and specifies the me vs omit/null semantics.

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 readOnlyHint/destructiveHint/openWorldHint annotations, the description discloses non-obvious behaviors: the operation is not idempotent, it creates only the primary language, and the returned structuredContent.fields carries question codes that should be read before constructing formulas. These are valuable traits not available in the annotations.

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

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

Six sentences, each earning its place: purpose, usage pattern, scene constraint, response/flow, language scope, and idempotency warning. The order is logical and there is no redundancy.

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

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

For a 9-parameter tool with nested objects, the description covers the critical non-schema facts: when to pass questions/report together, how to handle generated codes, scene-specific requirements, language scope, and retry safety. Since an output schema exists, return values are already covered structurally.

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%, giving a baseline of 3. The description adds useful cross-parameter workflow: report.outcomes is required with trueOutcomes/falseOutcomes in the outcome_quiz scene, and report.formula/dimensionAnalysis depend on server-generated question codes. However, the example 'q_a + q_b' omits the required `{{ }}` wrappers that the schema explicitly mandates, making it slightly unreliable.

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 'Create a form in the team this token is bound to', a specific verb+resource+scope statement. It further distinguishes from siblings by explaining that questions and report configuration are created in one call, and by pointing to create_form_translation for other languages.

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 states when to use this tool ('Pass the questions array and report configuration in one call instead of following up with per-question calls') and names alternatives: create_form_translation for additional languages, and update_form / set_dimension_analysis for post-create report configuration. It also provides a clear retry-after-timeout guideline.

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

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

Beyond the annotations (mutation allowed, not read-only), the description proactively discloses the non-idempotent behavior: 'if the call times out it may still have succeeded, so retrying blindly can create a duplicate — check first, then retry only if it is really missing.' It also details exactly what is cloned (structure, scoring/report config, visual settings, all language versions), which is materially useful context not captured by annotations or schema.

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

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

All four sentences earn their place: purpose, scoping/cloning detail, guidance on alternatives, and a critical non-idempotency warning. The main verb and object are front-loaded, and there is no redundant fluff.

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 tool with an output schema, the description covers everything needed: what it creates, where to get template IDs, what is cloned, how to override the title, how to adjust afterward, when to prefer it, and the retry caveat. With an output schema present, return values need no further explanation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by telling the agent to 'find template ids with list_templates' — a concrete source for the templateId parameter — and by clarifying the title override behavior, even though the schema already mentions the default. This extra guidance lifts it to a 4.

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

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

The description opens with a specific action and resource: 'Create a new form in the current team from a public template.' It distinguishes itself from siblings by explicitly referencing create_form as the alternative to build from scratch and by mentioning subsequent adjustability via update_form/update_question, so an agent can tell this tool apart without opening schemas.

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

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

The description gives clear when-to-use guidance: 'prefer it over building from scratch with create_form' when a suitable template exists. It also points to list_templates for finding template IDs and notes post-creation adjustment with update_form/update_question, making both the selection and follow-up path 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 are minimal (readOnly=false, destructive=false), so the description carries behavioral context. It discloses the cloning behavior, that the return value is the draft to edit, the language constraint, and the at-most-one-per-language rule. No contradiction with annotations.

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

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

Three sentences, each earning its place: the core action, the workflow and next step, and the constraints. The most important information is front-loaded, and there is no padding 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?

The description covers the creation workflow, the return behavior, the uniqueness constraint, and points to the relevant sibling tool. With an output schema and fully documented parameters, this is nearly complete; the only minor gap is explicit error behavior for duplicate or same-primary-language attempts.

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

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

The schema already documents both parameters at 100% coverage, including the language constraint. The description restates the language constraint without adding new parameter-level detail, so it neither adds nor detracts beyond the baseline.

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

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

The description clearly states the action ('Add a language version (translation) to a form') and the resource (a form translation). It also distinguishes itself from siblings like update_form_translation and delete_form_translation by describing the creation-specific clone-and-return behavior.

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

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

The description gives a concrete workflow: create, edit the draft, then save with update_form_translation, and it points to list_form_translations for the one-per-language constraint. It does not explicitly state 'use update_form_translation if a translation already exists,' but the workflow and uniqueness constraint imply this 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 convey destructive intent, but the description adds substantial behavioral context: the soft-delete behavior, hiding from list_forms, 5-day retention and auto-purge, reversibility via restore_form, owner/team-owner authorization, and preservation of submission records. This goes well beyond the structured annotation data.

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

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

Three dense, purposeful sentences, each contributing essential information: the action and scope, lifecycle and recovery behavior, and permission requirements plus submission handling. No filler or redundant repetition of schema content.

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

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

The description is complete for this tool's complexity: it covers scope, effects, recovery, retention, permissions, and data preservation. With an output schema present, return values need not be described, and the annotation set already covers read/destructiveness.

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 parameter formId is fully described in the schema itself. The description doesn't add extra parameter-level detail, but none is needed given the simple one-parameter interface.

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: 'Move a form into the trash (soft delete)'. It clearly distinguishes itself from siblings by explicitly contrasting with list_forms and restore_form, and by describing the soft-delete semantics.

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

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

Provides explicit context for when to use the tool: when you want to soft-delete a form. It names restore_form as the way to undo, specifies the 5-day recoverable window, and gives an explicit permission constraint ('Only the form owner / team owner can delete'), which acts as a when-not condition.

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

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

Beyond the destructiveHint=true annotation, the description discloses important non-obvious consequences: submission records are NOT deleted, reports for historical records fall back to source text, and the primary language is not removable through this operation. This is precisely the behavioral context an agent needs before invoking a destructive 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?

Three short sentences, each earning its place: the first states the action, the second explains data-retention implications, and the third states the primary-language exclusion. The essential scoping is front-loaded, with no redundancy or extraneous detail.

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

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

For a destructive operation with an output schema and annotations already present, the description covers all the necessary context: what is deleted, what is preserved, fallback behavior for reports, and a hard constraint on the primary language. No critical operational information is missing.

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

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

Schema description coverage is 100%, so both formId and language are already documented in the schema. The description's phrase 'language version (translation)' reinforces the meaning of the language parameter and clarifies that formId refers to the source form, but it does not add substantial parameter-level detail beyond what the schema already provides.

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

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

The description names the exact verb and resource: 'Delete one language version (translation) of a form.' It clearly distinguishes this from delete_form by specifying the object is a translation/language version, and it adds the critical constraint that the primary language cannot be deleted.

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 makes the tool's scope clear: deleting a language version is the intended use, and deleting the primary language is explicitly excluded. It does not explicitly name an alternative tool like delete_form for that case, so it stops short of perfectly explicit routing, but the usage context is otherwise unambiguous.

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 mark the tool destructive, so the description doesn't need to restate that. It adds valuable behavior beyond the annotation by stating that deleting the last element is permitted and that a form can end up as an empty shell. No contradiction with annotations 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?

The description is two sentences with no filler. The main purpose is front-loaded, and the important boundary behavior about deleting the last item is separated cleanly. Every sentence earns its place.

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

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

For a simple two-parameter destructive tool with an output schema and destructiveHint annotation, the description provides all essential calling context: what gets deleted, how it is identified, and the notable edge case. There are no major gaps that would prevent correct invocation.

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

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

The input schema already documents both parameters at 100% coverage with clear descriptions. The description adds extra meaning by revealing that 'code' may refer to either a question or a page break (Breaker), which broadens the interpretation of the schema's 'question' term.

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 states a specific action ('Delete'), a precise resource ('a single question or a page break (Breaker) from a form'), and the identifier used ('by code'). This distinguishes it from sibling tools like delete_form, which deletes the entire form. There is no ambiguity about what this tool operates on.

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 clear context: it is for removing an individual question/breaker from a form, not the whole form. It also clarifies an important edge case—deleting the last item is allowed—so an agent knows not to avoid calling it for fear of invalidating a form. However, it does not explicitly mention alternatives like delete_form or update_question.

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

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

The description goes well beyond annotations by detailing side effects: it creates a brand-new form with fresh share links, does not copy submissions/integrations/ban state, and is explicitly non-idempotent with timeout-ambiguity warnings. This is exactly the kind of behavioral context an agent needs beyond readOnly/destructive hints.

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 structured effectively: main action and scope first, then exclusions, use case, and a critical non-idempotency warning. Every sentence carries meaningful information with no redundancy or 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?

Given the tool's complexity—mutating, with timeout ambiguity and precise copy/exclusion semantics—the description covers everything needed to call it correctly. It explains what happens, what does not happen, when to use it, and how to handle retries. An output schema exists, so return-value documentation is not required here.

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

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

Schema coverage is 100% and both parameters already have clear descriptions in the schema. The description adds general context about ownership and fresh links but no extra parameter-level semantics, so the baseline of 3 is appropriate.

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

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

The description clearly states the verb 'duplicate' with a specific resource ('a form in the current team') and enumerates exactly what is cloned and what is not copied, such as submission records and sharing. This active scoping differentiates it from related form tools like create_form or create_form_from_template without needing to open schemas.

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 clear context: 'Useful for cloning a proven quiz and tweaking it.' It also gives guidance on retry behavior after a timeout. It does not explicitly name alternatives or state when not to use this tool, but the intended use case is clear enough for an agent to select it appropriately.

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 description discloses the side effect of recording the image in the team media library and the verification step, which goes beyond the annotations and schema. Annotations only say readOnlyHint=false, so the description usefully clarifies that this is a mutating finalization step, not merely a metadata 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 sentences with no wasted words. The prerequisite and step ordering are front-loaded, the action and outcome are stated, and the follow-up usage is a single targeted sentence.

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

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

With an output schema present, the description need not spell out the return shape; it still mentions media id + public URL. Combined with the explicit prepare_image_upload prerequisite and update_form consumer guidance, an agent has everything needed to invoke this tool correctly.

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

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

Schema description coverage is 100%, and each parameter already carries accurate context: key is the object key from prepare_image_upload, filename must match the prepare call, mimeType is the prepare-time MIME type, and alt is optional. The description reinforces the flow but adds no new parameter-level 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?

The description names a clear action ('call this AFTER you have PUT the file'), a specific resource (the uploaded object / team media library), and a concrete outcome (verifies, records, returns a media id + public URL). It clearly distinguishes itself from prepare_image_upload by framing it as 'Step 2 of 2'.

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 explicitly sequenced: it must be called after the PUT to the uploadUrl from prepare_image_upload, and the description gives a follow-up path via update_form for covers. It does not explicitly state when not to call it, but the protocol is unambiguous.

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 mark this read-only and non-destructive, so the safety bar is met. The description adds meaningful behavior beyond annotations: all write tools default to this tenant, and the examineeSignupDisabled flag has operational consequences for login-gated quizzes. This is exactly the kind of context an agent needs.

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

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

The core purpose is front-loaded in the first sentence, followed by the tenant-default behavior and then the flag explanation. Every sentence adds distinct value, and the practical troubleshooting tip is phrased efficiently.

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

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

With no parameters, an output schema, and read-only annotations, the remaining burden is explaining what the output means and when to care. The description does that thoroughly, including the exact login scenarios affected by examineeSignupDisabled.

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

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

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify, and the schema already confirms an empty input. No deduction is warranted.

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 starts with a clear verb and resource: 'Return the team (tenant) this token is currently operating against.' It also names the secondary returned signal, examineeSignupDisabled. It doesn't explicitly name or contrast a sibling like switch_active_tenant, so it doesn't fully earn the sibling-differentiation point, but the purpose is unambiguous.

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

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

It gives a concrete use case: check this tool before diagnosing why nobody can submit, and explains how the signup-disabled flag affects login-gated quizzes. It doesn't mention alternatives or exclusions, but for a read-only getter with no parameters, this is useful contextual 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 signal read-only and non-destructive, and the description adds meaningful behavior beyond that: the enabled:false return case, server-side range clamping, and the special exclusion of a booking's own slot when rescheduling. These are exactly the non-obvious behavioral details an agent needs.

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

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

Four dense sentences with no filler, front-loaded with the primary action and followed by edge cases and usage guidance. Every sentence earns its place and adds information an agent cannot reliably infer from schema or annotations alone.

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

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

For a read-only availability tool with an output schema, annotations, and related siblings, the description covers the core behavior, failure mode (enabled:false), range limiting, rescheduling prerequisite, and bookingId semantics. Nothing material is missing for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine value for bookingId by explaining its rescheduling purpose and the 'own slot is not counted as taken' behavior. It also clarifies that date ranges may be clamped server-side, going beyond the schema's basic field 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?

States a specific verb 'Read' and resource 'the current team's bookable time slots in a date range', and explains how the slots are computed ('weekly booking rules minus what is already taken'). This clearly distinguishes it from booking-management siblings like list_bookings or update_booking_status.

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 instructs to call this before reschedule_booking, explains why ('a start time outside the available slots is rejected'), and tells when to pass bookingId. This gives an agent a clear decision rule for when and how to use the tool.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds useful behavioral context beyond annotations: 'Sensitive auth fields are never returned' and that customData is included. This helps an agent understand the response boundary.

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 sentences with no filler. The core behavior and key parameter are front-loaded, and the sensitive-field caveat is placed as a concise follow-up. 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?

Given an output schema exists and the tool has only one parameter, the description is complete. It states scope (current team), the ID source, included data (customData), and an important exclusion (sensitive auth fields). No critical information needed 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 the schema already fully documents examineeId as the business ID shown in list_examinees. The description repeats this example and adds the alias 'respondent,' but it does not meaningfully extend the parameter semantics beyond what the schema provides.

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

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

The description uses a specific verb ('View the full detail of one examinee'), names the resource ('examinee / respondent'), and specifies the lookup key ('examineeId'). It clearly distinguishes this from list_examinees and update_examinee by indicating it returns the full detail of a single examinee, including customData.

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

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

The description gives clear context: it is for viewing one examinee by business ID, scoped to the current team, and references list_examinees as the source of the ID. It does not explicitly state when not to use it or mention alternatives, but the single-resource vs. list distinction is implied strongly enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: it identifies where outcome codes live (report.outcomeAnalysis.outcomes) and clarifies the meaning of language fields in the response.

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

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

Three sentences carry substantial, non-redundant information. The main purpose is front-loaded, and the follow-up sentences add only high-value context about outcome analysis and translation languages.

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

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

For a read-only single-form retrieval tool with one required parameter and an output schema, the description is complete: it states scope, what is returned, and two edge-context behaviors. Nothing essential for the agent to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters well. The description mentions fields[] and report configuration, which loosely map to includeFields and includeReport, but does not add meaningful parameter-level detail beyond the schema.

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

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

The description opens with a specific verb and resource: 'View one form of the current team in full,' and clarifies what is included (questions list fields[] and report configuration). This clearly distinguishes it from siblings like list_forms and get_form_translation.

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

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

The description gives clear context: use it to view a single form in detail, including raw question data and report config. It does not explicitly name alternatives or exclusions, but the scope is unambiguous enough to guide selection among the many sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful context beyond that: the scope ('in the current team'), the telemetry source ('form_sessions'), and the exact stage/breakdown details. No contradiction with annotations.

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

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

The description is dense but not bloated. It front-loads the verb and resource, uses a colon to organize the breakdown list, and ends with a practical usage sentence. Every segment contributes information, though the enumeration is long.

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

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

With an output schema present, the description only needs to convey scope, timing, and intended use, which it does thoroughly. It covers the team scope, the look-back window, the breakdown dimensions, and the drop-off analysis use case. Nothing needed for correct invocation is missing.

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

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

Schema description coverage is 100%, so both formId and days are already documented with defaults and bounds. The description only echoes 'form' and 'last N days' without adding new parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Read the conversion funnel for a form...' and enumerates the exact breakdowns available (overall stages, per-channel, UTM combos, drop-offs). This clearly differentiates it from sibling tools like get_form_stats or list_records.

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

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

It states a clear use case: 'Use this to find where respondents drop and improve conversion.' It does not explicitly name alternatives or when-not-to-use scenarios, but the funnel-specific context makes the appropriate usage apparent.

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 the description reinforces this by presenting only read-oriented outputs like 'current delivery settings' and by explicitly deferring changes to update_form_settings. It adds meaningful behavioral detail beyond annotations, such as how omitted or invalid utmSource affects the embed script's forwarding of utm_* parameters.

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 dense but efficient, front-loading the main value proposition and then compactly guiding usage. It is a long first sentence, but each listed item contributes to the output picture without unnecessary 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?

Given a rich output schema, high parameter coverage, and explicit annotations, the description covers all essential operational context: what the tool returns, when to use it, how to pass the optional channel tag, and which sibling tool handles modifications. Nothing needed for a correct call is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds useful semantic context for utmSource by explaining its channel-tagging purpose and effect on all links and snippets. It also functionally signals that iframeHeight and popupButtonText are optional output customizations, though the schema already documents them well.

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

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

The description states a clear, specific purpose: retrieving everything needed to share a form, including the public answer link, custom domain status, embed snippets, and delivery settings. It clearly distinguishes this read-only retrieval tool from siblings like update_form_settings by naming the tool that performs the mutation.

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 explicitly says when to use the tool: to answer 'give me the link / the embed code' and to sanity-check a launch. It also directs the user to update_form_settings when changes are needed, providing a clear alternative and excluding misuse.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description starts with 'Read', which is consistent. It adds meaningful behavioral context by specifying team scoping, the time window, and the full breadth of returned statistics, giving the agent a good sense of what an invocation will produce. It does not cover performance or rate limits, but the annotations and output schema lower the burden.

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 dense but every element earns its place: the opening verb/resource/scope, the detailed list of returned statistics, and the closing use case. It is front-loaded with the core action and uses an em-dash list to keep the information structured and scannable.

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

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

Given the tool's moderate complexity, the 100% schema coverage, the presence of an output schema, and annotations covering safety, the description is complete. It explains what the tool does, what data it operates on, the team scope, the time-window parameter, and the intended usage. Nothing essential is missing for an agent to call it correctly.

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

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

Schema coverage is 100%: formId and days both have descriptions in the input schema. The description reinforces the meaning of days ('last N days') and adds the 'current team' scope, but it does not add parameter-level detail beyond the schema, so the baseline of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Read submission statistics for a form in the current team over the last N days.' It then enumerates the exact categories of statistics returned, making it easy to distinguish from the form CRUD siblings and from get_form_funnel even without opening the schema.

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

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

The description gives an explicit intended use: 'Use this to gauge how a quiz is performing and to suggest improvements.' It does not mention alternatives or exclusions, but the clear use case and the read-only scoping in the first sentence provide enough context for an agent to select it appropriately.

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 readOnlyHint annotation, the description discloses concrete behavior: it returns an error when the language version does not exist yet, includes mirrored fields[] and report in the result, and assumes a specific editing workflow. This is meaningful behavioral context that is not present in the annotations or schema 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 sentences, each earning its place: the first states what the tool does, the second gives workflow guidance, and the third covers the error case and prerequisite. Information is front-loaded and there is no redundancy or fluff.

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 (two parameters) and has a full output schema, so return-value details need not be repeated. The description covers the success case, error case, prerequisite, and how this tool fits into the broader translation workflow, making it complete for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so both formId and language are already fully described, including the language enum. The description does not add parameter-level details beyond what the schema provides, so the high-coverage baseline of 3 is appropriate.

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

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

The description clearly states the operation: 'Read the full content of one language version (translation) of a form.' It also specifies what is included ('mirrored fields[] and report') and distinguishes this read tool from related siblings like update_form_translation and create_form_translation.

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 explicitly tells the agent when to use this tool ('Use this to fetch the current draft before translating') and names the follow-up tool ('save with update_form_translation'). It also gives an important exclusion condition: if the language version doesn't exist, create it first with create_form_translation.

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 signal read-only and non-destructive behavior, and the description adds task-relevant context such as current-team scoping, optional inclusions, and the leadId/examineeId addressing rule. It does not cover error cases or defaults, but the annotation safety profile lowers the burden.

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 dense paragraph with a front-loaded purpose, a colon-delimited payload list, and a closing ID rule. It is information-dense without filler; only the somewhat run-on structure prevents 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?

With annotations, an output schema, and full schema parameter coverage, the description is contextually adequate: it states what is returned, which flags affect breadth, and the team/ID scoping. It does not state exact when-to-use alternatives, but that is a minor gap for a single-item getter.

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

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

Schema coverage is 100%, so the baseline is 3. The description's optional-inclusions wording maps loosely to the boolean flags but adds no parameter details beyond what the schema already provides.

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

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

Description names a specific verb ('View'), a resource ('one lead of the current team'), a key ('leadId'), and enumerates what is included. This clearly distinguishes get_lead from list_leads and get_examinee without needing to open the schema.

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

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

It gives clear context: use this for a single lead scoped to the current team, and it supplies an explicit identifier constraint ('never by a masked email'). It does not explicitly name sibling alternatives such as list_leads for multi-lead views, so it falls short of a full 5.

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

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

Beyond the readOnlyHint and destructiveHint annotations, it discloses meaningful behavior: the returned report is frozen, answers are returned as written, and email addresses or phone numbers are masked. It also clarifies team scope and that the full report structure is included.

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 front-loaded with the core purpose, then efficiently enumerates the significant output components and a special masking behavior. Every sentence carries useful information without filler or unnecessary 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 single-parameter read tool with rich annotations and an output schema, the description supplies all necessary context: what the record contains, how to identify it, current-team scope, and the masking caveat. 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 description essentially restates the schema's parameter explanation: recordId is the id from list_records. The description adds no new details about the parameter's format, constraints, or behavior beyond what the schema already provides.

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

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

The description opens with a precise verb and resource: 'View the full detail of one submission record (lead)...' and explicitly scopes it by record id, distinguishing it from list_records and other sibling tools like get_lead. It clearly states what the returned detail includes.

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 clearly implies when to use it: when you need full detail for one record identified by the id from list_records. It does not explicitly state when not to use it or name alternatives, but the scoping and id reference give solid 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?

The annotations are all false/neutral (readOnlyHint=false, destructiveHint=false), so the description carries the burden and delivers: it discloses that the call is not idempotent, that a timeout may still mean success, that blind retries can duplicate items, and prescribes a check-then-retry strategy. This is exactly the kind of non-obvious behavioral trait an agent needs. It stops short of a 5 only because it doesn't touch on post-success effects or reversibility.

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

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

Four sentences, zero filler. The core purpose is front-loaded, followed by the positioning mechanics, the sibling route for the end case, and the idempotency warning. Every sentence carries load and the most critical operational caveat (retry behavior) is placed last where the risk context has been built.

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 complex (26 params, nested choices/aiMatch) but the schema is exceptionally rich — every parameter documented and a long FIELD APPLICABILITY note covers per-type/per-scene rules — so the description need not restate parameters. It supplies exactly the missing operational layer: positioning semantics, the get_form reference mechanism, end-case routing, and retry policy. An output schema exists, so return values need no explanation. A 5 would require something additional the agent still needs that isn't covered.

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

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

Schema coverage is 100%, so the baseline is 3; the schema already documents every parameter thoroughly. The description adds genuine value on top for the positional parameters: after/before values come from get_form's field.code, and 'before the first field's code' is the front-insertion trick — detail the schema's terse 'Insert after this code; choose either after or before' does not convey.

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

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

The description opens with a specific verb+resource+scope: 'Insert an item (question or page break) at a specific position.' It immediately distinguishes itself from the sibling add_question by scoping to positional insertion (front/middle) versus appending, so an agent can tell them apart without reading either schema.

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

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

The description explicitly names the alternative and the selecting condition: 'To insert at the end, use add_question.' It also gives the mechanical recipe — reference existing field codes from get_form's field.code via after/before, and use before on the first field's code for front insertion. No inference is required.

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 (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description reveals the real-world side effect (sending an email), the authentication/role requirements, and all notable rejection cases such as already-member, pending invite, and member limit. This gives an agent a complete behavioral model without needing to invoke the 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?

The description is dense but every sentence earns its place: purpose, side effect, permissions, role constraints, failure modes, and team-targeting context are all covered in about four sentences. The core action is front-loaded, and there is no filler or repetition that would dilute an agent's attention.

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

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

For a tool with side effects, authorization constraints, and multiple failure paths, the description covers all the contextual information an agent needs: how the active tenant is determined, how to switch it, what roles are available, and exactly when the call will fail. The output schema covers the return shape, so the description need not expand further.

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

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

The schema already covers the role enum and the default, but the description adds meaning by clarifying that 'viewer' is read-only, that no one can be invited as owner, and that the invite fails for already-member or already-pending emails. This goes beyond the raw schema definitions and informs role choices.

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

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

The description opens with a specific verb and resource: 'Invite someone to the active team (tenant) by email.' It also states the side effect (sends an invitation email) and return value (the join link), leaving no ambiguity about what the tool does or how it differs from other team-management 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 explicitly says when the call is permitted (team owner or admin only) and rejected for other roles, and it gives concrete routing guidance: operate on the currently targeted team first, using list_my_tenants / switch_active_tenant to change teams. It also names the failure conditions that would make the call invalid.

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 convey readOnlyHint and non-destructive intent, and the description adds meaningful context: bookings are scoped to the current team, attendee names/emails come back masked, and statuses carry workflow semantics (pending = approval queue). No contradiction with annotations.

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

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

Four sentences, each carrying distinct useful information: scope/order, item fields, filter capabilities, typical use, and masking behavior. The description is well front-loaded and contains 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 read-only list operation with an output schema and safety annotations, the description adequately covers entity type, included fields, filtering, ordering, identification, and privacy masking. Pagination and sort details are left to the schema, which is acceptable.

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 input schema fully describes all 9 optional parameters with 100% coverage, so the description need not repeat per-parameter detail. It adds only a high-level filter summary and a bookingId reference for downstream use, which doesn't deepen parameter understanding 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?

Clearly states the verb 'List' and the resource '1:1 bookings of the current team', with a clarifying parenthetical about discovery calls/consultations and the default order. This differentiates it from sibling tools like list_leads and list_records without needing to open their schemas.

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

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

Provides a concrete typical use case ('status "pending" lists the approval queue waiting on someone') and summarizes filtering options, giving an agent a clear context for invocation. It does not explicitly name alternative tools for mutating bookings, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which cover the safety profile. The description adds significant behavior beyond the annotations: 'newest first' ordering, sensitive auth fields never returned, and the examineeId being returned unmasked for use in other tools. This is valuable context that an agent needs to interpret results correctly.

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

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

Three sentences, each earning its place: purpose and scope, data exclusion behavior, and routing to related tools. The key outcome 'newest first' is front-loaded, and there is no fluff or repetition of schema content.

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

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

For a list tool with an output schema already describing the response shape, the description completes the picture: it defines the resource, the team scope, ordering, sensitive-field redaction, and how the returned ID feeds into sibling tools. Nothing an agent needs to call or interpret this tool 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%, with each parameter (limit, search, status) already documented in the input schema. The description does not add parameter-level details such as formats or defaults — it focuses on result behavior. Baseline 3 is appropriate since the schema carries the parameter semantics.

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

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

The description clearly states the verb 'List' and the resource 'examinees', and even clarifies synonyms ('respondents'). It distinguishes itself from get_examinee by indicating that this returns a list while get_examinee returns full detail, making sibling differentiation explicit.

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

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

The description explicitly states when to use an alternative: 'Use get_examinee for one examinee's full detail including customData.' It also scopes usage to the current team and notes the returned examineeId as the input for get_examinee/update_examinee, giving clear 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 mark this as read-only and non-destructive; the description adds genuinely useful behaviors: reverse-chronological order by creation and omission of question content. No contradiction with annotations was found.

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 conveys the core action, scope, ordering, and content limitation without filler or redundancy. Every word earns its place.

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

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

For a simple read-only list tool with an output schema and fully documented optional filters, the description is adequate: it covers scope, ordering, and content omission. Minor details like whether deleted forms are included are not critical for correct invocation.

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

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

The input schema fully describes all three optional parameters (limit, scene, titleContains), so schema description coverage is 100%. The description adds no additional parameter-specific meaning, 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 ('List'), resource ('forms'), and scope ('current team'), and explicitly notes it excludes question content and routes to get_form for details. This clearly distinguishes it from sibling get_form and makes its scope unambiguous.

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

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

Explicitly points to get_form as the alternative when form details are needed, which gives a clear when-to-use signal. It does not mention other related siblings like list_templates, so differentiation from all alternatives is not fully covered.

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 mark this read-only and non-destructive; the description adds what specific data is returned (language, isActive, public share link, timestamps) and what is excluded. No side effects or surprising behavior are omitted.

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; the action and return value are front-loaded, and the primary-language caveat is placed as a short final note. Every sentence earns its place.

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

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

For a one-parameter read-only list tool with an output schema and full annotations, the description covers scope, return contents, and the key caveat. No additional information is needed to call it correctly.

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

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

Schema already documents formId as 'The source form UUID' with 100% coverage. The description only restates that these are translations of a form, adding no extra format or constraint semantics.

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

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

States verb 'List', resource 'existing language versions (translations) of a form', and explicitly distinguishes itself from get_form by noting the primary language is not included. This differentiates it from sibling translation CRUD tools without opening schemas.

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?

Clearly sets the boundary that the primary language lives on get_form.language, so an agent knows not to expect it here. It does not, however, mention when to prefer get_form_translation for a single translation, so routing guidance is partial.

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

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

Annotations declare readOnlyHint=true and destructiveHint=false, and the description does not contradict this. It adds valuable behavioral context: 'Newest activity first by default', 'Filter by status / assignee / tags / created-at range / keyword / whether they have an upcoming booking', and critical notes about server-side matching with masked emails and the half-open pagination/filtering behavior for hasUpcomingBooking. These details go beyond the schema and annotations, ensuring the agent knows exactly how filtering and data masking behave.

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

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

The description is well-structured: it opens with the primary function, then describes typical return contents and default sorting, followed by filtering options and important usage caveats. It is moderately concise, with every sentence adding value (e.g., the note about never guessing codes and the leadId/examineeId distinction). Some redundancy exists (filter list partially repeats schema), but overall it is efficient and front-loaded.

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

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

Given the tool has 10 parameters and an output schema exists, the description does not need to explain return values. It covers the key operational aspects: scope, default sort, filtering options, and essential preconditions (calling list_lead_settings). It also discloses the hasUpcomingBooking filtering nuance. Minor gaps include no mention of pagination behavior beyond the schema (though page/limit are self-explanatory in the schema) and no explicit note on performance/limits, but these are adequately addressed 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?

The schema description coverage is 100%, so the baseline is 3. While the description reinforces some param semantics (e.g., the need to use codes from list_lead_settings for status and tagCodes, and that keyword matches the real email server-side despite masking), it does not add significant meaning beyond what the schema already provides. The schema descriptions themselves are detailed, and the tool description offers only marginal additional parameter insight.

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 states the tool lists CRM leads for the current team, describes the fields returned (follow-up status, assignee, colour tags, submission count, next booking), and specifies default ordering. This differentiates it from siblings like list_records and get_lead, which have different purposes. The verb 'list' is specific and the resource is defined without ambiguity.

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

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

The description provides actionable guidance: call list_lead_settings to obtain valid status/tag codes and never guess, reference leads by leadId and respondents by examineeId. It also clarifies the scope ('of the current team' and 'across all forms'). While it does not explicitly mention alternative tools or when not to use this tool, the context is clear enough for an agent to decide when to invoke it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context: the read is scoped to the current team, and the values returned are not universally valid but team-specific, which directly affects downstream writes.

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 sentences with no filler. The first sentence states exactly what is read and the second gives actionable usage guidance. It is well front-loaded and 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?

Given that an output schema exists, the return format is already documented. The description provides the missing context an agent needs: when to call the tool, why team-specific values matter, and which sibling tools depend on its results. Nothing important is left unstated.

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

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

The tool has zero parameters, so the schema already fully defines inputs. The description adds no parameter-specific semantics because none are needed; it instead clarifies that the tool requires no inputs and simply reads current settings. This matches the baseline for parameterless tools.

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 ('Read'), a precise resource ('the current team's lead configuration'), and enumerates exactly what is returned: follow-up status codes with label, colour, and display order, the colour tag library, and assignable members. This clearly separates it from sibling write tools like update_lead, set_lead_tags, and assign_leads.

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 explicitly instructs the agent to call this tool before update_lead, set_lead_tags, and assign_leads, and explains why: status codes, tag codes, and member ids are team-specific and the write tools reject unknown values. This gives both a positive trigger and a concrete exclusion boundary.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to restate safety. It adds useful context beyond annotations by explaining that 'isActive marks the team this token currently operates against,' which clarifies the output semantics.

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 fully cover the tool's purpose and the key output field semantics. There is no filler or unnecessary detail.

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

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

For a zero-parameter read-only list tool with an output schema available, the description is complete. It states what is returned, the user scope, and the meaning of isActive, which is all an agent needs to invoke it correctly.

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

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

The input schema has zero parameters, so there is nothing for the description to explain about parameters. The baseline of 4 applies because no parameter documentation is needed.

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

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

The description is specific: 'List all teams (tenants) the current user belongs to' names the exact verb and resource. It also distinguishes itself from siblings like get_active_tenant and switch_active_tenant by clarifying it returns all tenant memberships, not just the current one.

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 makes the use case clear: call when you need the full set of tenants for the current user. However, it does not explicitly contrast with get_active_tenant or switch_active_tenant, so an agent must infer when this tool is preferable to those alternatives.

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

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

Even though readOnlyHint=true and destructiveHint=false are already annotated, the description adds useful behavioral context: records are returned newest first, email/phone values inside answers are masked, and respondents must be referenced by examineeId rather than masked email. These are non-obvious behaviors not present in the annotations.

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

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

Four purposeful sentences, front-loaded with the verb and resource, with no filler or repetition. Each sentence adds value: scope/ordering, item composition, filters, masking warning, and routing to get_record.

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 input schema covers pagination and filtering, the output schema covers the item shape, and the description adds scope, ordering, masking, and an explicit alternative for full-record retrieval. Nothing needed to invoke it correctly is missing.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description only paraphrases the existing filter parameters ('form, report status, and submitted-at range') without adding new syntax or format details. The schema already carries the parameter meaning.

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

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

The description opens with a specific verb-resource pair ('List submission records (leads)'), defines scope ('current team'), ordering ('newest first'), and names the included fields, including compact report results, UTM metadata, and examinee info. It also explicitly contrasts itself with get_record for full detail, distinguishing it from the closest sibling.

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

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

The description gives clear context for when to use this tool: when listing or filtering submission records, and explicitly directs the agent to get_record when one record's full detail is needed. However, it does not explicitly distinguish itself from the sibling list_leads, leaving a possible ambiguity without an exclusion.

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

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

Annotations already signal readOnlyHint=true and destructiveHint=false, so the description adds useful behavioral context: only active templates are returned, the library is public, and results are sorted by usage count. This goes beyond the schema and aligns with the annotations.

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

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

Two tight sentences with no filler: the first front-loads the resource, fields, and sort order; the second gives a concrete downstream action. Every phrase earns its place.

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

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

With annotations covering safety and an output schema present, the description provides the essential scoping (active/public/most-used) and the intended workflow. An agent has everything needed to select and invoke this tool correctly.

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

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

Schema coverage is 100%, and all five parameters already have descriptions in the input schema. The description does not add parameter-level detail, but it does clarify the return context and sort behavior, which is helpful though not required.

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

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

States a specific verb and resource: 'List active templates in the public template library,' and enumerates the returned fields and sort order. This clearly distinguishes the tool from siblings like list_forms because it targets the public template library rather than user-created forms.

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

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

Explicitly says when to use the tool: 'Use this to find a template, then call create_form_from_template with its id to create a form from it.' It gives the workflow but does not explicitly state when not to use it or name an alternative listing tool, though the intent is clear.

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

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

Annotations indicate a mutation (readOnlyHint=false) but do not detail side effects. The description adds useful context on the after/before mechanics and the front/end positioning, going slightly beyond the schema. However, it does not disclose what happens if both after and before are provided, if the referenced code does not exist, or whether the operation is reversible—gaps that the description could address given minimal annotation coverage.

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

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

The description is two sentences, with the core purpose front-loaded and no redundant phrasing. Every sentence contributes: the first states the action and object, the second explains the after/before options and how to achieve front/end placement. It is concise and well-structured.

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

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

Given the tool's moderate complexity (4 params, output schema present) and the existence of siblings, the description covers the essential usage scenarios. It explains the after/before logic and front/end moves. It does not mention error handling or prerequisites, but these are not critical for an agent to invoke the tool correctly. The output schema reduces the need to describe return values.

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 value by explaining how to use after/before for front/end positioning, which is not in the schema. It also clarifies that 'code' refers to a question or a Breaker (page break), adding semantic meaning beyond the schema's generic 'field code'.

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 states the verb and resource: 'Move an existing question or page break to a specific position by code.' It also specifies the mechanism (after/before) and distinguishes this from sibling tools like insert_question or update_question by focusing on repositioning existing elements rather than adding or editing content.

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 explicit instructions on when to use this tool and how to use its parameters: 'Choose either after or before, referencing another field's code.' It also explains how to move to the front and end. While it doesn't explicitly name alternatives or state when not to use it, the context makes it clear this is for reordering, and the front/end tips add practical 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 provide readOnlyHint=true and destructiveHint=false, but the description adds critical behavioral context: it returns a short-lived presigned URL, rejects uploads >5MB, only accepts four MIME types, and that the authoritative check happens in finalize_image_upload. This goes well beyond annotations and clarifies the two-step mechanism.

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?

Long but every sentence earns its place. The workflow is numbered and front-loaded with purpose. Examples (sips, magick, curl) are concrete and useful, not fluff. Structure is logical: what it does, what it doesn't do, steps, constraints.

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?

Comprehensive for a complex two-step upload with output schema. Covers all parameters, constraints, workflow, sibling linkage, and error conditions (size rejection). No missing information an agent needs to call it correctly. Output schema presumably documents the returned URL and key.

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

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

Schema coverage is 100%, so baseline is 3. The description enriches fileSize ('of the file you will actually upload, after any compression', checked against 5MB cap and quota up front) and clarifies filename purpose ('for admin display / download'). It adds meaningful details beyond the schema without redundancy.

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 states 'Step 1 of 2 for adding an image ... to the current team media library' with explicit resource (image upload), verb (prepare), and context. It distinguishes itself from finalize_image_upload and lists accepted types. No ambiguity.

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

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

Provides a numbered workflow (steps 1-6) including exact conditions: compress if >5MB, accepted MIME types, explicit statement that this tool does NOT receive bytes, and names the sibling finalize_image_upload. Tells when not to use (e.g., non-image files, over 5MB after compression). Fully covers when and how.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description's 'Read the guide' framing reinforces the read-only nature and enumerates the guide's contents, but it does not add behavioral traits beyond what annotations provide—no auth needs, side effects, or response-shape caveats.

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

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

Two sentences with zero waste. The first sentence front-loads what the tool provides, and the second delivers the actionable usage instruction. Every sentence earns its place and no redundant phrases appear.

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-only documentation tool with no output schema, the description is nearly complete: it lists the returned content and states when to call it. A minor gap is that it never explicitly states the response is the guide text itself, though the content enumeration strongly implies 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%: the single enum parameter `type` already explains each value (quiz, scorecard, outcome) with concrete meaning. The description adds only the implicit mapping that the chosen type selects which guide to read, which is consistent but not a substantive addition beyond the schema's own explanations.

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 purpose: an authoring guide containing field schema, question types, scoring rules, themes, common mistakes, and a worked example for a RooQuiz preview type. It also distinguishes itself from siblings by explicitly naming preview_quiz, preview_scorecard, and preview_outcome, so an agent can tell it apart without opening their schemas.

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

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

The description gives an explicit usage directive: 'Read the guide for the type you want before calling preview_quiz, preview_scorecard, preview_outcome.' This names the exact alternatives and the condition under which this tool should be invoked, leaving nothing to inference.

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

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

Annotations already cover read-only/write and destructive hints, and the description adds meaningful behavioral context beyond them: no account/login/API key required, produces a browser link, takes only the finished assessment JSON, and forces 'scene' to 'outcome_quiz'. It does not discuss persistence or side effects, but the annotations plus these details give a solid behavioral picture.

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 front-loaded with the core purpose and then delivers usage guidance, alternatives, prerequisites, and parameter constraints in a compact sequence. Every sentence contributes new information; there is no filler or repetition of the input schema.

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

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

For a tool with one parameter, a rich output schema, and clear sibling definitions, the description covers all needed decision points: what the tool does, when to use it, when not to, authentication requirements, schema prerequisites, and a self-remediating instruction to call preview_guide if context is missing. Nothing essential 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?

Schema description coverage is 100% and there is only one parameter, form, which already describes the expected JSON shape. The description adds value by stating that the tool takes 'the finished assessment JSON and nothing else,' clarifying that no additional credentials or options are needed, and by pointing to preview_guide as the source of the schema.

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

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

The description opens with a specific verb and resource: 'Create a shareable RooQuiz preview personality / outcome test' and immediately explains the voting mechanism. It also distinguishes itself from siblings by naming preview-quiz and preview-scorecard as different quiz types, so an agent can choose correctly without opening schemas.

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 explicitly states when to use this tool ('Use this when someone wants to build, try out, or share a personality quiz...') and gives alternatives with contrasting conditions: right/wrong graded quizzes go to preview-quiz, scored questionnaires go to preview-scorecard. It also provides a clear prerequisite: call preview_guide with type 'outcome' first unless the schema is already in 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 flag readOnly=false, destructive=false, and the description adds context beyond them: no account/login/API key required, the tool consumes a finished JSON and nothing else, and the output is a browser-openable share link. It does not detail side effects beyond creation, but the preview/try-out framing plus existing annotations cover the safety profile.

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 paragraphs: the first front-loads purpose and sibling disambiguation, the second covers the input contract and prerequisite. Minor redundancy between the appositive description of a graded quiz and the later 'graded quiz... with correct answers and a final score' phrase keeps it just short of flawless.

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

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

With an output schema present and a single nested object parameter, the description covers everything needed: purpose, use cases, alternatives, prerequisite, auth requirements, and input shape pointer. No material gap remains for an agent to call it correctly.

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

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

Schema coverage is 100% for the single 'form' object, and the schema itself documents the shape source (preview_guide) and the forced 'scene' value. The description reinforces this with 'takes the finished assessment JSON and nothing else,' which clarifies that the parameter must be the complete, ready-to-use artifact.

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 outcome — 'Create a shareable RooQuiz preview quiz... and get a link to open in the browser' — with the grading model spelled out (right/wrong, points, score). It also names the sibling skills it is not (preview-scorecard, preview-outcome), so an agent can reliably tell the three preview tools apart.

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

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

Gives explicit when-to-use criteria ('when someone wants to build, try out, or share a graded quiz, test, trivia, or exam'), names the two alternatives with their distinguishing conditions, and states the prerequisite to call preview_guide with type 'quiz' when the schema isn't already in 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?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses that no account/login/API key is required, that the tool forces 'scene' to 'scored_quiz', that it returns a shareable browser link, and that it accepts only finished assessment JSON. These are useful behavioral facts not expressed in the structured fields; only minor details like validation-error behavior are omitted.

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

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

Four dense sentences, purpose front-loaded before usage, alternatives, and precondition. Every sentence carries distinct information: the definition, the no-auth constraint, the routing rules, and the preview_guide dependency. The length is fully justified by the three-way sibling routing complexity; there is 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?

Given that an output schema exists, return-value documentation is unnecessary. The description covers the entire decision surface: selection criteria, exclusions naming both alternatives, input sourcing via preview_guide, and auth requirements. An agent can correctly select and prepare an invocation from this text alone.

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% — the form parameter is already documented with its shape, the reference to preview_guide for the structure, and the forced 'scene' value. The description adds modest reinforcement ('takes the finished assessment JSON and nothing else') but no substantive new parameter semantics, 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?

Opens with a specific verb+resource ('Create a shareable RooQuiz preview scorecard') and immediately defines the concept ('each option adds points toward a total that buckets into levels'). It also states what it is not — no 'correct' answer — which distinguishes it from the graded-quiz sibling without requiring schema inspection.

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

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

Explicitly says 'Use this when' and enumerates concrete scenarios (self-assessment, health/habit score, readiness/maturity check, satisfaction survey). It then routes to alternatives with precise conditions: 'For a right/wrong graded quiz, use the preview-quiz skill; for a personality/type test with no scores, use the preview-outcome skill.' It also states a precondition to call preview_guide if the schema is not already in 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?

Goes well beyond the annotations by disclosing concrete side effects: the attendee is emailed, the 24h reminder is re-armed, and the booking.rescheduled integration event fires. It also exposes failure modes such as a taken slot or another active booking, adding meaningful behavioral context.

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

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

The description is compact and well-structured: one sentence each for the core purpose, prerequisite workflow, side effects, and failure conditions. No filler or redundant restatement of the tool name 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?

Covers the key elements an agent needs: what the tool does, who may use it, how to obtain a valid parameter, what side effects occur, and when it will fail. Since an output schema exists, omitting the return shape is acceptable.

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

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

The schema already describes both parameters well, so the baseline is a 3. The description adds value by specifying the proper workflow dependency: call get_booking_availability with this bookingId first and select startAt from its slots, which clarifies how the two parameters relate.

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

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

States a specific action and object: 'Move a confirmed booking of the current team to a different time, as the organiser.' It also adds role and state constraints ('confirmed', 'scheduled', 'organiser') that make it clearly distinct from sibling tools like review_booking or update_booking_status.

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 instructs the agent to first call get_booking_availability with the bookingId and pick a startAt from its slots, and states the rejection conditions. It does not explicitly name alternative tools to prefer instead, but the prerequisite workflow and operational constraints are clearly conveyed.

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

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

Beyond the annotations, the description discloses important behavioral traits: permission requirements and an error condition when the form is not in the trash. It also makes the inverse relationship to delete_form explicit, which helps the agent predict side effects.

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

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

The description is a single efficient sentence with no filler. It front-loads the primary action and scope, then packs in the permission and error conditions without bloating the 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 tool with an output schema and annotations, this description is complete. It covers purpose, scope, preconditions, permissions, and a failure case, giving an agent enough information to select and invoke the tool correctly.

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

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

The schema already provides 100% coverage for the single formId parameter, so the description does not need to add much. It reinforces the semantic link to the trash but does not add detail beyond the schema's 'form UUID' description.

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

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

The description states a specific action ('Restore a form from the trash') with the resource scope ('in the current team') and explicitly frames it as 'undo delete_form'. This clearly differentiates it from sibling tools like delete_form, update_form, and duplicate_form.

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

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

It provides clear conditions for use: the form must be in the trash, within the current team, and only the form owner or team owner can perform the restore. It does not explicitly enumerate alternatives, but the 'undo delete_form' linkage gives enough context for an agent to decide when to use it.

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

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

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses the key side effects: confirming the meeting, sending the confirmation with the meeting address, sending a decline note, optionally using meeting link/instructions with team-level fallback, and permission restrictions. This is exactly the behavioral context an agent needs for a mutating, externally-visible action.

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 dense but well-structured, with the core action front-loaded and every clause carrying operational meaning. It avoids filler and packs preconditions, side effects, parameter exceptions, fallback behavior, and authorization into a compact block.

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 state-changing booking review tool, it covers preconditions, decision outcomes, email notifications, parameter-specific behavior, fallback semantics, and authorization. With an output schema present, return-value documentation is not required, and nothing critical to selecting or invoking the tool is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds useful cross-parameter meaning by tying decision=approve to address release and meetingLink/meetingInstructions, and decision=decline to declineReason, while clarifying fallback behavior. This adds value but mostly reinforces what the parameter descriptions already state.

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

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

The description opens with a specific verb-resource pair ('Approve or decline a pending booking request') and immediately explains the resulting state transition and external effects. It is clearly distinct from list_bookings and reschedule_booking, though it does not explicitly contrast itself with the sibling update_booking_status for non-pending status changes.

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

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

It gives explicit applicability conditions: only pending bookings can be reviewed, past meeting times can only be declined, and only team owners/admins or lead owners can perform the review. It does not explicitly say when to prefer update_booking_status or list the exclusions for confirmed/cancelled bookings, so it stops short of full alternative 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?

The annotations only indicate a mutating operation, so the description carries the behavioral burden. It clearly discloses that the whole dimensionAnalysis is replaced, that overallAnalysis is preserved, that an empty array clears the configuration, and that the tool is unsupported for random_knowledge_quiz forms. This goes well beyond the annotations without contradicting them.

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 compact and front-loaded, with every sentence carrying useful information: replacement semantics, scene requirements, clearing behavior, prerequisite action, and an unsupported case. There is no filler or repetition of schema details.

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

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

For a tool with nested parameters and scene-dependent requirements, the description is complete enough to invoke correctly. It covers replacement semantics, clearing, unsupported form types, and the get_form prerequisite, while the output schema and rich parameter descriptions handle the remaining detail.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning by tying fieldCodes to knowledge_quiz and formula to scored_quiz, and by recommending get_form as a prerequisite. This helps the agent reason about scene-dependent parameters more efficiently than reading each schema field alone.

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

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

The description uses a specific verb ('Set') with an exact resource ('multi-dimension analysis (form.report.dimensionAnalysis)') and states the replacement semantics. It also distinguishes itself by explicitly saying it replaces the analysis as a whole while not touching overallAnalysis, which separates it from other form-update siblings.

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

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

The description gives clear usage context: call get_form first to read question codes, pass an empty dimensions array to clear, and avoid random_knowledge_quiz forms. It does not explicitly name a sibling alternative tool for the unsupported case, but it still provides strong when-to-use and prerequisite 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?

The description discloses key behavioral traits: the 'replace' mode overwrites the whole tag set (potentially destructive), 'remove' accepts stale codes, and changes are recorded on each lead's timeline. Annotations only declare readOnlyHint false and destructiveHint false, but the description adds meaningful context about side effects and what happens to existing tags, going 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?

The description is moderately long but every sentence carries load-bearing information. It opens with the primary purpose, then the critical batching constraint, then mode semantics, then tag library reference, then behavioral note. It could be slightly more compact (e.g., merging some clauses), but it is well-structured and free of fluff.

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

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

Given the presence of an output schema (Has output schema: true) and a 100% schema description coverage, the description needs to cover only operational context, which it does comprehensively. It addresses batching limits, mode selection, tag validation rules, and side-effect logging. No essential information for correct invocation is missing.

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

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

The schema already covers parameters with descriptions (leadIds max 50, tags from list_lead_settings.tags[].code, mode enum). The description adds substantial semantics beyond the schema: it explains the practical difference between modes, justifies batch usage, and notes that 'remove' accepts stale codes. This is high-value enrichment that helps the agent choose correct parameter values.

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 verb and resource: 'Set the colour tags on one or more leads.' It clearly indicates the tool's function and distinguishes it from related operations like update_lead or assign_leads by focusing on tag manipulation. The mention of 'current team' adds scope, while the instruction to pass all lead ids in a single call sets it apart from potential per-lead 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?

The description provides explicit when-to-use guidance, including the prohibition against looping ('do not loop'), and explains the three modes ('replace', 'add', 'remove') with specific scenarios for each (e.g., 'replace' for editing a single lead, 'add'/'remove' for batches). It also directs users to the tag library via list_lead_settings.tags, making the usage contextfully complete.

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

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

Annotations already mark the operation as non-read-only and non-destructive. The description adds meaningful behavioral detail: persistence across sessions and the membership requirement. This goes beyond what the annotations 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 sentences, each earning its place: one states the action and scope, the other states persistence and the caller prerequisite. 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 single-parameter tool with full schema coverage and an output schema, the description supplies the essential behavioral context: persistence, token scope, and membership requirement. Nothing critical is missing.

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

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

The schema fully documents tenantId with its own description and a pointer to list_my_tenants. The main description does not add parameter-level meaning beyond the schema, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Switch') and resource ('active team (tenant) for this token'), making the operation unmistakable. It is clearly distinct from siblings like get_active_tenant, which reads rather than changes state.

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 clear context: the switch persists across sessions and requires membership in the target team. It does not explicitly name alternatives or exclusions, but the behavioral context is sufficient for a tool with this scope.

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