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

No annotations are provided, so the description must carry the behavioral disclosure burden. It adds one meaningful consequence: attribution reporting keys off this attachment. However, it does not state whether the operation is idempotent, what happens on re-attachment, or any permission/error implications.

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 concise sentences with no filler: the first states the purpose, the second adds actionable timing and reasoning. Both sentences earn their 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 relationship-creation tool, it provides the core information: the action, the target campaign, the supported asset kinds, and best timing. It omits ID lookup details and side-effect specifics, but an output schema exists and sibling tools like list_campaigns and list_campaign_assets fill some gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It helps clarify asset_type by listing valid categories (page, post, email, form), but still leaves campaign_id and asset_id formats and meanings unexplained, and the asset_type values are not exact enum strings.

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 exactly what it does: attach a page, post, email, or form to a campaign. This clearly distinguishes it from siblings like detach_asset_from_campaign and list_campaign_assets.

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 concrete timing guidance: 'worth doing at the point the draft is created rather than later,' and explains why via attribution reporting. It does not explicitly mention alternatives or when not to use it, but the context is clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly warns that HubSpot's legacy API may not reliably cancel schedules created via v3, instructs the agent to tell the user to verify in the UI, and details the user_confirmed parameter, clarifying that content read from HubSpot is not confirmation. This is exemplary transparency for a mutation tool.

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

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

The description is efficient and well-structured: a one-sentence purpose, then a caveat and user-action requirement, then an Args section. Every sentence contributes essential information. It is slightly longer than the minimum but not padded, and the critical behavioral notes are 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?

The tool has three parameters, no annotations, and an output schema (so return format is covered by schema). The description covers the purpose, usage context, parameter meanings, safety caveats, and a required post-action step (user confirmation). Nothing an agent needs 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 0%, so the description must compensate. It does so comprehensively: content_id is defined as 'page or blog post ID,' content_kind is constrained to 'page' or 'post,' and user_confirmed is explained in depth, including when it should be True and why. This adds meaning far beyond the schema's type and enum definitions.

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 object: 'Cancel a pending scheduled publish.' This clearly distinguishes it from siblings like unpublish_page or unpublish_blog_post, which target live content, whereas this targets a scheduled action. The scope 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?

The description clearly implies when to use it: to cancel a pending scheduled publish. It provides context about the legacy API and instructs the agent to ask the user to confirm afterwards. It doesn't explicitly name alternatives or exclusion conditions, but the purpose is so specific that an agent can infer the correct usage scenario.

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

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

No annotations are provided, so the description carries the transparency burden. It does add one key behavioral fact: the post is created in DRAFT state and is not publishd immediately. But it does not disclose permission requirements, duplicate-slug behavior, validation rules, or side effects on existing resources.

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 opens with a one-sentence purpose and follows with a compact, structured Args list. There is no filler; each line adds operational information an agent needs.

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

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

For a 9-parameter tool with no annotations and an output schema present, the description is nearly complete: it explains all parameters, supplies format constraints, and points to sibling lookup tools. It is only missing explicit handling notes for edge cases like duplicate slugs or invalid tag IDs.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. Each parameter receives a meaningful hint beyond its name: slug format, language default, HubSpot-hosted image requirement, and references to list_blogs and list_blog_authors for ID lookup.

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

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

The description names a specific resource ('blog post'), a clear verb ('Create'), and a distinctive state ('DRAFT'). It is immediately distinguishable from sibling tools like create_landing_page_draft, create_site_page_draft, and update_blog_post_draft.

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 'DRAFT state' phrasing implies this is the tool for creating a new, unpublishd blog post rather than updating or publishing one. However, it never explicitly states when not to use it or names alternatives, so routing guidance is only implied.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses a crucial side effect: 'Nothing here goes live, and nothing here is visible to the public,' which tells the agent that creating a campaign is a safe, private bookkeeping action. It does not mention permissions or idempotency, but the most important consequence is covered.

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 tightly structured: a one-line summary, an Args list, and a single clarifying sentence about campaign behavior. Every line earns its place, and there is no redundant or filler prose.

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 straightforward creation tool with an output schema present, the description covers the purpose, all parameters, and the key non-public nature of campaigns. It does not explicitly discuss permissions or alternate approaches, but an agent has enough to call this tool correctly. A small gap is the lack of explicit routing guidance among the many sibling tools.

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

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

Schema description coverage is 0%, so the description must compensate, and it does. It explains that 'name' is the only HubSpot requirement, gives exact date formats for start_date and end_date, clarifies goal as free text, and describes properties as 'any further hs_* properties.' This adds real meaning beyond the bare schema types and defaults.

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 campaign.' It then clarifies that a campaign is a 'planning container' and contrasts it with public/live content, which distinguishes this from sibling tools like create_blog_post_draft or create_landing_page_draft. The purpose is unmistakable.

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

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

The description gives clear contextual guidance by stating that campaigns never go live and are never visible to the public, so an agent can infer this is for internal planning rather than publishing. It does not explicitly name alternatives or state when-not-to-use, but the context is strong enough to steer selection away from content creation siblings.

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

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

With no annotations, the description carries full behavioral burden. It discloses key side effects: immediate liveness, non-embedding, and lack of consent settings. It stops short of covering error conditions, rate limits, or auth requirements, but for a create operation the most critical behaviors are transparently stated.

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 lengthy but every section serves a purpose—the live/draft distinction, the parameter documentation, and the consent caveat. It is structured with an Args block that aids scanning. It could be trimmed slightly, but the density is justified given the tool's complexity.

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 all five parameters, the behavioral implications, and the consent gap. An output schema exists, so return format need not be detailed. For a create tool with a nested fields structure, this is fully sufficient 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 0%, so the description is the sole source of parameter meaning. It provides exhaustive documentation: a detailed field spec with types, examples, required fields, and per-type notes; descriptions for all other parameters; and a note about consent that explains why it's omitted. This fully compensates for the schema's emptiness.

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 verb and resource ('Create a HubSpot form') and immediately distinguishes it from draft-based tools by emphasizing it is not a draft and becomes live instantly. This differentiates it from sibling create_*_draft tools and clarifies its unique nature.

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 strong usage context: it explains the form is live but not embedded, instructs the agent to tell the user this, and notes that consent must be configured separately. It does not explicitly name alternative tools, but the draft distinction and consent guidance make the intended usage 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?

No annotations are provided, so the description carries the behavioral burden. It discloses that the page is created in DRAFT state, imposes slug formatting rules, explains the domain default behavior, and requires the featured image to be hosted in HubSpot. These are concrete behaviors beyond the bare 'create' action, though it does not cover error cases or auth requirements.

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

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

The one-sentence summary is front-loaded, followed by a compact per-parameter list with no filler, repetition, or unnecessary prose. Every line adds meaningful information.

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

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

Given the 9-parameter surface with no schema descriptions, the description does a thorough job covering each parameter and key behavioral constraints. The output schema exists, so the return value need not be described. The only minor gap is the lack of explicit differentiation from the closely related create_site_page_draft sibling.

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

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

Schema description coverage is 0%, so the description is the only documentation for all 9 parameters. It explains semantics for every parameter, including the template source ('from list_templates'), slug constraints, ISO language code default, the optional domain behavior, and the nature of layout_sections. This fully compensates for the empty schema descriptions.

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

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

The description opens with a specific verb and resource: 'Create a new landing page in DRAFT state.' It clearly distinguishes this from sibling tools like create_site_page_draft by naming the resource and state, and the summary is not a tautology.

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 useful contextual guidance, such as using list_templates to fill template_path and only supplying domain when the portal has several domains. However, it never explicitly says when to choose this tool over alternatives like create_site_page_draft or mentions when not to use it, so the routing is left to inference.

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

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

With no annotations, the description carries the full burden. It transparently discloses two important behaviors: the variant joins the source's multi-language group, and the tool does not translate. However, it does not state whether the variant is created as a draft or immediately published, nor does it mention permissions or other side effects, which are nontrivial gaps for a create operation.

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 the core purpose, followed by key behavioral caveats and a clearly formatted parameter list. Every sentence contributes useful information without repetition 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?

Given the tool has 5 parameters, an output schema, and no annotations, the description covers the essential purpose, behavior, and parameter semantics well. It is slightly incomplete in that it doesn't clarify draft versus live state or explicitly route users away from related tools like duplicate_page, but those are minor given the strong parameter and behavior coverage.

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

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

Schema description coverage is 0%, and the description compensates by explaining all five parameters: source page ID, source type values, ISO 639-1 language code, explicit slug, and translated module content override. This adds real meaning beyond the bare schema, especially for target_language and layout_sections_override.

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 language variant of an existing page, e.g. EN from a DE page.' This unambiguously distinguishes it from generic draft-creation or duplication siblings, and the multi-language group detail clarifies the intended result.

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 the tool: when you need a localized variant that joins the source's multi-language group and should appear in the language switcher. It does not explicitly name alternatives or exclusion conditions, but the 'existing page' and 'language variant' framing implies the right selection criteria.

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

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

With no annotations, the description carries the full behavioral burden and does so well: it discloses the DRAFT-only side effect, the precedence of widgets over html_body, and HubSpot's template requirement. It does not cover failure modes or permissions, but for a create operation the side-effect disclosure is strong.

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 docstring is longer than average, but every line maps to a distinct parameter or behavioral detail. The bulleted Args format is scannable, and the critical draft-only side effect is front-loaded. There is no filler or redundant boilerplate.

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 0% schema coverage and absence of annotations are fully compensated: all input parameters, defaults, precedence rules, and the draft-only outcome are explained. Since an output schema exists, the description does not need to explain return values, and nothing essential is missing for calling 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 0%, so the description must supply all parameter meaning, and it does for all 12 parameters. It explains the relationship between html_body and widgets, provides a concrete template_path example, lists the valid email_type values, and clarifies portal and business-unit scoping.

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

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

The opening sentence states the exact operation: create a marketing email in DRAFT state, which clearly identifies the resource and outcome. This distinguishes it from sibling tools like update_marketing_email_draft and publish_marketing_email. The second sentence reinforces that nothing is scheduled or sent.

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 creating a new marketing email draft. The statement 'Nothing is scheduled or sent' tells the agent this is not the tool for sending or publishing. It does not explicitly name sibling alternatives such as update_marketing_email_draft or publish_marketing_email, 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?

With no annotations, the description must carry behavioral disclosure. It states the draft state, which is useful, but it does not explain side effects, whether the draft is saved only, what validation occurs, or any consequences of creation.

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 one short sentence that front-loads the core purpose and state. It contains no filler and efficiently points to a sibling for argument 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?

Given 9 parameters, no annotations, and zero schema descriptions, the tool is under-specified. The description lacks parameter meanings, usage guidance, and behavioral details beyond 'DRAFT'. An output schema exists, but it does not compensate for the missing explanatory information.

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

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

Schema description coverage is 0% for 9 parameters skillfully, and the description does not explain any parameter beyond referencing create_landing_page_draft. This delegation might help if the sibling is known, but it adds no concrete semantics for the current tool.

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

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

The description clearly states the verb 'Create', the resource 'site page', and the state 'DRAFT'. It also points to a sibling tool, create_landing_page_draft, which helps distinguish this tool from closely related creation 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?

No guidance is given for when to use this tool vs alternatives like create_landing_page_draft or create_blog_post_draft. The phrase 'Same arguments as create_landing_page_draft' addresses parameter reuse but not usage context or exclusions.

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

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

With no annotations, the description bears the full disclosure burden. It partially succeeds by stating that the asset itself is untouched, revealing a key non-destructive behavior. However, it omits other behavioral aspects such as reversibility, permissions, or 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?

Two short sentences, with the primary action front-loaded and the clarifying nuance added immediately. Every word earns its place; there is zero 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?

Despite an output schema, the description is too sparse for reliable invocation. It lacks essential parameter details like valid asset_type values and assumes the user knows prerequisites. The absence of annotations makes this gap more severe.

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

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

Schema description coverage is 0%, so the description must compensate, but it provides no explanation of campaign_id, asset_type, or asset_id. It does not clarify acceptable asset_type values or how the parameters relate, leaving an agent guessing.

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 ('Remove') and resource ('asset from a campaign'), and adds the critical nuance that the asset itself is untouched. This clearly distinguishes it from deletion tools and pairs naturally with attach_asset_to_campaign.

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 usage context is implied by the name and sibling tool attach_asset_to_campaign, but there is no explicit when-to-use or when-not-to-use guidance. The description does not mention alternatives or conditions for choosing this 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?

No annotations are provided, so the description carries the behavioral burden. It does disclose the core semantics: it copies field definitions and settings under a new name and requires label translation afterward. It does not mention permissions, whether the source form remains untouched, or what the new form's publish/draft state is, leaving some behavioral uncertainty.

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: the purpose and use case appear in the first line, followed by the specific copy behavior and a useful next step. The Args block is minimal and necessary given the lack of schema descriptions. There is no filler or repetition heavy enough to cost a point.

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, the description does not need to document return values. It covers the use case, copy behavior, follow-up translation step, and both parameters. The main completeness gap is that it routes the agent to update_form_draft, which is not among the listed siblings, and it does not clarify how this relates to create_language_variant.

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

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

Schema description coverage is 0%, so the Args section is the only explanatory documentation. It adds real meaning: source_id is 'ID of the form to copy' and new_name is 'name for the copy.' It does not provide constraints such as uniqueness or length, but for two plain string parameters the semantics are sufficiently clear.

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

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

The first line states the exact action and resource: 'Duplicate a form' and adds the canonical use case: 'the usual way to make a second-language variant.' The second sentence clarifies the copy scope ('field definitions and settings') and that a new name is given, which distinguishes this from generic form creation and other duplication 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 gives clear context for when to use the tool: when making a second-language variant, and it even names the follow-up step of translating labels via update_form_draft. It does not, however, explicitly state when not to use it or compare it with alternatives like create_language_variant, and the referenced update_form_draft is not present in the sibling-tool list.

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

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

With no annotations, the description carries the full behavioral burden, but it only restates the copy action. It does not disclose side effects such as whether a new draft is created, whether the source email is left untouched, or whether any permissions/special state are required.

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

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

The definition is two efficient sentences plus a compact Args list. The primary action is front-loaded, the workflow hint earns its place, and 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 simple two-parameter operation with an output schema present, this is close to sufficient. However, because annotations are absent, the description should clarify what the duplication produces (e.g., a new draft copy versus a published duplicate) to fully guide correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for both parameters. It does: source_id is documented as "ID of the email to copy" and new_name as "internal name for the copy," adding real meaning beyond the bare property names.

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

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

The description states a specific verb and resource: "Duplicate a marketing email." The resource phrase also distinguishes it from sibling duplication tools like duplicate_page and duplicate_form, and the newsletter hint gives an immediate sense of the intended workflow.

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

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

The phrase "the usual way to start next month's newsletter" implies a common usage scenario, but it never explicitly says when to choose this tool over create_marketing_email_draft or other siblings, nor does it state any exclusions or prerequisites.

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

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

With no annotations, the description carries the transparency burden. It usefully discloses that the result is a DRAFT (not published), that HubSpot derives new_slug if omitted, and that overrides follow update_page_draft's keys. It doesn't cover permissions or failure modes, but the key behavioral traits are conveyed.

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 a memorable use case, then moves into a compact but complete Args list. Every sentence adds information; there is no filler or redundancy.

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

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

All five parameters are explained, the draft behavior is clear, and the overrides field is delegated to update_page_draft's schema, which is an efficient cross-reference. The output schema exists, so return values need no description. Slight gaps remain around source-page prerequisites and edge cases, but overall it is complete enough for correct invocation.

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

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

Schema description coverage is 0%, so the description must document parameters itself. It does so thoroughly: source_type is defined as 'landing' or 'site', new_slug's default behavior is explained, and overrides are tied to update_page_draft with a concrete example. This fully compensates for the schema's lack of descriptions.

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

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

The description states exactly what the tool does: 'Duplicate an existing page as a new DRAFT, optionally applying overrides.' It names the verb, resource, and output state, and the 'workhorse' example distinguishes it from creating a page from scratch or duplicating forms/emails.

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 concrete use case — 'take last quarter's webcast page and make this quarter's version out of it' — clearly tells an agent when to use this tool: when copying an existing page. It does not explicitly name alternatives like create_landing_page_draft or create_site_page_draft, but the context is strong enough to steer selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals that the tool never publishes, defaults output_filename and timezone, strips directory parts from filenames, returns a warnings list for overly long messages, and identifies the most common cause of rejection (account name mismatch).

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 densely informative, organized into clear sections with Args, required vs. optional distinction, and return values. Every sentence adds operational value, such as the account-mismatch warning and the fact that the tool never publishes.

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 three parameters, one required, the description fully covers input semantics, constraints, defaults, output shape, failure hints, and safety expectations. Nothing an agent needs 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?

The input schema has 0% description coverage, so the description must fully compensate. It does: it defines each posts requirement (account, scheduled_at, message), lists optional fields (link_url, image_url), provides concrete examples, states the 300-post maximum, and explains output_filename and timezone defaults and behaviors.

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

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

The description states a specific verb and resource: 'Write a HubSpot-format Excel file for scheduling social posts in bulk.' It clearly distinguishes this from the sibling tools, which are mostly list/create/publish operations for pages, blog posts, and emails rather than file generation for social scheduling.

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

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

It explains exactly when to use this tool: since HubSpot has no public social publishing API, this is the supported route, with the subsequent upload path (Marketing → Social → 'Schedule in bulk'). It also clarifies what the tool does not do — it never publishes — and notes that HubSpot previews every post before publication, giving the agent appropriate context for invoking 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?

There are no annotations, so the description carries the full transparency burden. It discloses that include_content returns the full postBody HTML and warns that it is large, and it clarifies the draft vs live behavior. It does not mention errors, permissions, or read-only guarantees, but 'Fetch' already conveys read-only intent.

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 scannable, with a one-line purpose followed by tight parameter bullets. Every sentence adds useful information, and the most important caveats (large post bodies, draft default) are front-loaded.

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

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

For a simple fetch tool with an output schema, the description covers all invocation-relevant details: what to pass, what content to expect, and which version is read. The main gap is the absence of explicit routing guidance against sibling tools, but this is a minor omission given the clear purpose.

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

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

Schema description coverage is 0%, and the description fully compensates by explaining all three parameters: post_id is the HubSpot blog post ID, include_content controls full postBody HTML with a size warning, and draft distinguishes draft from live versions. This is exactly the semantic value the schema lacks.

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 'Fetch one blog post,' a specific verb and resource that clearly distinguishes this from siblings like list_blog_posts and get_page. The singular focus and ID-based parameter make its purpose 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?

The description gives useful parameter-level guidance, such as 'leave this off unless you need to edit them' for include_content and explaining draft vs live. However, it never explicitly says when to choose get_blog_post over list_blog_posts or get_page; the selection context is only implied by the word 'one.'

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

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

With no annotations, the description carries the full burden. "Read" communicates a safe, non-mutating operation, and the properties hint discloses that the response's richness depends on the parameter. However, it does not cover error behavior (e.g., not-found handling), the meaning of "basics" vs. "metrics," or what exactly happens when properties is 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 sentences with zero waste. The core action is front-loaded, and the second sentence earns its place by explaining the optional parameter's purpose. No redundant language.

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

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

For a low-complexity tool — 2 params, one required, output schema present — the description is reasonably complete: it states the operation, the parameter needed, and how to get extended data. The output schema covers return structure. The main gaps are tool-selection guidance versus list_campaigns and examples of valid property values, but these are minor for this complexity level.

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

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

Schema description coverage is 0%, so the description must compensate. It does add meaning to `properties` — the schema only says 'Properties' with an array-of-strings type, while the description explains it requests metrics beyond basics. However, `campaign_id` gets no semantic help (though self-evident), and the description never clarifies what string values `properties` accepts.

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

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

The description states a specific verb and resource: "Read one campaign." The singular 'one' implicitly distinguishes it from list_campaigns, and the verb 'Read' separates it from create/update/duplicate siblings. However, it never names a sibling explicitly, so differentiation is implied rather than stated.

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

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

The description implies usage context — you call this when you need a single campaign's details rather than a list — but it never states when to use this over list_campaigns or other siblings. The second sentence, "Pass `properties` for metrics beyond the basics," is param-level guidance, not tool-selection guidance. No exclusions or alternatives are given.

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

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

With no annotations, the description carries the full behavioral burden. It explains what include_fields does (returns fieldGroups tree vs summary), but it contradicts the schema by claiming 'True (default)' while the schema sets default to false. It also omits any mention of error handling, permissions, or side effects, leaving significant behavioral gaps for a read operation.

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

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

The description is short and front-loaded with the purpose, followed by concise parameter explanations. It is well-structured as a docstring, though the default value inaccuracy slightly detracts from clarity. Overall, it is appropriately sized with no wasted words.

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

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

Given the output schema exists, return values need not be explained, but the tool's correct usage is compromised by the include_fields default mismatch. The description also does not cover potential errors, prerequisites, or the meaning of 'summary' vs 'fieldGroups tree' in sufficient depth. For a simple fetch tool, it is incomplete due to the inconsistency.

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 description adds meaning by specifying form_id as a UUID and explaining include_fields' effect on output. However, the default for include_fields is stated incorrectly (True vs schema's false), which is misleading. Since schema description coverage is 0%, the description must compensate, but this error undermines its usefulness.

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 'Fetch one form', specifying the verb and resource. It distinguishes from sibling tools like list_forms, which lists multiple forms, and other get_* tools for different entities. 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?

The description implies this tool is for retrieving a single form by ID, but it does not explicitly state when to use it versus alternatives like list_forms, nor does it mention any exclusions. Usage context is implied by the name and purpose rather than spelled out.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the tool is read-only ('Fetch'), that include_content returns a large payload, and that draft defaults to True. This covers the most important behavioral traits an agent needs to avoid unintended expensive or wrong-version calls.

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 Purpose line is front-loaded, followed by a compact Args block. Every sentence earns its place, and there is no redundant or vague 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 output schema exists, return values don't need explanation. The description covers the one required param, the two optional params, their defaults, and the key tradeoff of include_content. 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 0%, so the description must fully compensate. It does: email_id is identified as a HubSpot email ID, include_content is explained as the full content/widgets tree with a size warning, and draft's True/False meaning is stated. All three parameters gain real semantic value beyond their schema titles.

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 opening line, 'Fetch one marketing email,' is a specific verb+resource statement that clearly distinguishes this single-item getter from sibling list_marketing_emails. It is immediately obvious what the tool does and which resource it targets.

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 param-level guidance: include_content should only be set when editing content, and draft controls whether to read the draft or live version. It does not explicitly name an alternative tool for listing or finding emails, but the usage context for the main decision points 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?

With no annotations, the description carries the full transparency burden and succeeds: it reveals that layoutSections is omitted by default due to size, that include_content is needed for module content, and what the draft parameter does. These are non-obvious behaviors not present in the schema.

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

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

The description is compact and front-loaded: purpose first, then the key omission behavior, then parameter explanations. Every sentence adds information, and the Args block earns its place because schema descriptions are absent.

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 and has an output schema, so return values need not be described. The description supplies the only hidden context an agent needs: default content trimming, draft mode, and when to request full content. Nothing essential is missing.

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

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

Schema coverage is 0%, so the description must explain every parameter, and it does. It defines all four args, adds meaning to include_content (only before editing) and draft (draft vs live), and clarifies page_type 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 opens with the specific operation 'Fetch one landing or site page,' naming both verb and resource. The word 'one' and the page_type split clearly differentiate it from the list_* sibling tools 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?

It gives clear operational context: a single page fetch with a compact default, and instructs to set include_content only when about to edit module content. It does not explicitly name alternative get/list tools for different resources, but the single-page scope and page_type constrain when it applies.

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

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

There are no annotations, so the description carries the full burden. 'List' implies a non-destructive read operation, and the limit behavior is documented, but the description does not disclose whether the returned authors are ordered, filtered, or restricted by permissions. This is acceptable for a simple list but not highly transparent.

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 extremely concise: one purpose sentence plus one parameter explanation. There is no filler or redundant restating of the tool name, and the most important information is front-loaded.

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

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

For a simple list tool with one optional parameter and an output schema, the description covers the essential invocation context: what the tool returns and how to constrain the result. It could be slightly more complete by noting whether the list is exhaustive or capped, but the default and maximum limit make the behavior clear enough.

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 provides no description for the 'limit' property, but the tool description documents its maximum range (1-100) and default (100). This fully compensates for the 0% schema description coverage for the only parameter.

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

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

The description opens with a specific verb and resource: 'List blog authors'. It goes beyond the tool name by stating the intended use case ('for setting author_id on a blog post draft'), which also distinguishes it from sibling tools like list_blog_posts and list_blogs.

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

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

The phrase 'for setting author_id on a blog post draft' clearly indicates when to use this tool. It does not explicitly name alternatives or exclusions, but no sibling tool has the same purpose, so the guidance is sufficient for an agent to select 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?

No annotations are provided, so the description carries the behavioral burden. It discloses filtering semantics, state values, defaults, and limit constraints, which is useful. However, it does not mention sorting, pagination behavior, or response structure beyond the existence of an output schema, and it does not explicitly confirm the operation is read-only.

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

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

The description is a one-line summary followed by a tight Args list with no filler. Every line adds either a format, constraint, default, or cross-reference, and the most important parameter semantics are 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?

With six optional parameters and no annotation coverage, the description covers every parameter's semantics and defaults, which is essential. The presence of an output schema covers return shape, but the description omits ordering and pagination details beyond limit, leaving a small gap for a list tool.

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

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

Schema description coverage is 0%, and the description fully compensates by explaining all six parameters with formats, constraints, and defaults. It adds case-insensitivity for name_contains, allowed state values, ISO 639-1 and ISO 8601 formats, and the 1-100 limit range—meaningful detail not present in the bare 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 opening line 'List blog posts' names a specific verb and resource, and the parameter list clarifies that this is a filtered retrieval operation, not a mutation. It does not explicitly contrast itself with siblings like get_blog_post or list_blog_authors, but the plural resource and filter arguments make the intent clear.

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

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

The description provides no explicit 'use when' or 'instead of' guidance, aside from a brief pointer to list_blogs for resolving blog_id. It leaves the choice between this tool and related tools such as get_blog_post or list_blog_authors entirely implicit.

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

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

With no annotations, the description carries the behavioral transparency burden. It discloses that the tool lists portal-level blog instancesparen rather than posts, and that it exposes blog_id values needed by another tool. While it does not explicitly state side effects or filters, the list operation and its output purpose are clearly communicated.

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 redundancy. It front-loads the action, provides clarifying examples, and then gives a concrete use case. 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 zero-parameter list tool with an output schema, the description is complete. It tells the agent what the tool lists, gives examples, and explains how the result will be used. Nothing important 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?

The tool has zero parametersharein, so the schema already covers everything. The description adds useful downstream context about blog_id, but there are no parameter semantics to clarify. Baseline 4 for zero-parameter tools 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 a specific verb and resource: 'List the blog instances in the portal.' It reinforces the distinction with concrete examples ('a marketing blog and a tech blog') and explains the intended outcome ('get the blog_id'), making it easy to distinguish from sibling tools like list_blog_posts.

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 usage context: 'Use this first to get the blog_id that create_blog_post_draft needs.' This tells the agent when to call the tool. It does not explicitly mention alternatives or when not to use it, but the downstream workflow guidance is strong and relevant.

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

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

No annotations are provided, so the description carries the full burden. It only says 'List', which implies a read operation, but it does not disclose pagination, sorting, auth requirements, or any other behavioral traits. It adds little beyond the tool name and bare purpose.

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 clear sentence followed by a compact argument list. Every line earns its place and there is no redundant or filler 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?

The tool is simple, has an output schema, and both parameters are mentioned. However, it lacks behavioral context such as pagination, result scope, or any caveats, and gives no guidance on selecting between related list tools. It is adequate but has clear gaps.

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

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

Schema coverage is 0%, so the description must compensate. It does for asset_type by listing all valid enum values, but campaign_id is only described as 'the campaign', which adds almost no meaning beyond the parameter name.

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

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

The description states a specific verb ('List') and resource ('assets attached to a campaign'), making the operation immediately clear. This also distinguishes it from sibling tools like list_campaigns and asset-specific listers such as list_landing_pages.

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 tool's intended use is implied by its purpose: use it when you need the assets attached to a campaign. However, it provides no explicit guidance about when not to use it or how it compares to sibling list tools like list_landing_pages or list_blogs.

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

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

With no annotations, the description carries the behavioral burden. It explains pagination semantics ('after: paging cursor from a previous call'), limits, and sort syntax, and the 'List' verb implies read-only behavior. It does not disclose default sorting or potential error conditions, but for a straightforward read-only list this is reasonably transparent.

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: a clear one-line purpose, a helpful one-sentence contextual analogy, and a concise Args block. No words are wasted, and the most important info is front-loaded.

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

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

Given three optional parameters, no required arguments, and an output schema present, the description covers everything needed to call the tool correctly. It explains the resource, the pagination model, sorting, and the conceptual purpose. Missing return-field details are handled by the output schema.

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

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

Schema description coverage is 0%, so the description fully compensates by explaining all three parameters: limit's range, after's role as a paging cursor, and sort's syntax with '-' prefix for reverse. This is meaningful guidance beyond the bare schema.

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

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

The description states a specific verb and resource ('List marketing campaigns') and names the key output dimensions (dates and goals). The editorial-calendar analogy also helps distinguish this from sibling operations like list_campaign_assets or get_campaign.

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 editorial-calendar framing provides a clear context for when this tool is the right choice: when you need a date-oriented view of campaigns. It does not explicitly list exclusions or name alternative tools for specific use cases, so it falls short of full 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?

No annotations are provided, so the description carries the burden of behavioral disclosure. 'List' clearly implies a read-only retrieval operation, and the scope is stated as domains connected to the portal. However, it does not explicitly mention side effects, authentication requirements, or whether pagination beyond the limit is handled.

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

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

The description is brief and well-structured: a single-sentence functional summary, a one-line use-case rationale, and a minimal Args section. Every sentence is informative and no unnecessary detail is included.

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 one optional parameter, an output schema present, and a simple read operation, the description is complete enough. It covers what the tool returns conceptually, when to use it, and fully documents the only parameter, including its range and default.

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

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

Schema description coverage is 0%, so the description must compensate. It does: the Args section specifies that `limit` controls maximum results, enforces a range of 1-100, and gives the default of 100. The schema only lists the default, so this adds valuable constraints.

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

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

The description opens with a clear verb and resource: 'List domains connected to the portal.' This precisely identifies both the operation and its scope, and it is easily distinguished from sibling list tools like list_blogs and list_forms, which cover different resources.

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

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

The description provides a concrete use case: when a portal serves multiple domains and a page needs an explicit `domain` on creation. This helps an agent understand when to call the tool, though it does not mention explicit alternatives or exclusions.

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

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

There are no annotations, so the description carries the burden of behavioral disclosure. It usefully explains parameter behavior (case-insensitive substring, limit range, default), but it does not state whether the operation is read-only, how results are ordered, or how paging behavior works. 'List' implies read-only, but that is implicit rather than explicit.

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

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

The description is three lines: a one-sentence purpose followed by two concise parameter bullets. Every clause adds information, there is no redundancy, and the most important facts are front-loaded.

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

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

For a simple list tool with an output schema and two well-documented optional parameters, the description covers the essential calling information. It lacks usage guidance and explicit behavioral notes like sorting or pagination, but these are minor given the presence of an output schema and the straightforward nature of the operation.

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

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

Schema description coverage is 0%, so the description must provide semantic meaning for parameters. It fully does: name_contains is described as a case-insensitive substring, and limit is described with a range and default. This adds substantial value beyond the raw type/default information in the schema.

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

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

The description states a clear verb and resource: 'List forms in the portal.' It is easily distinguished from more specific form tools like get_form and from non-form list tools by the resource namewach, though it does not explicitly contrast itself with those 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?

There is no guidance about when to use this tool versus alternatives such as get_form, list_site_pages, or other list_* tools. The parameters suggest filtering use, but no context, exclusions, or recommended scenarios are provided.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses that name_contains matching is client-side across several pages and that results may include a note when the search is cut short, which is genuinely behavioral information. However, it does not mention auth requirements, rate limits, or clarify that this is a read-only operation, though 'list' strongly implies it.

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

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

The description is a compact docstring with a one-line summary, an Args block, and a one-line Returns note. Every line adds necessary information, and the structure is front-loaded with the tool's purpose. It avoids fluff while still defining defaults and formats.

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 return dict shape, filter defaults, and the edge-case note when the search is cut short. With an output schema present, it does not need to fully enumerate return fields. It is slightly short on operational details like explicit pagination behavior beyond mentioning client-side multi-page matching, but for an optional-parameter list tool this is adequate.

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

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

Schema description coverage is 0%, so the description must supply parameter semantics, and it does so thoroughly. name_contains is defined as a case-insensitive substring, state has an enumerated default of ANY, language expects ISO 639-1, updated_after expects ISO 8601, and limit has a numeric range and default. This fully compensates for the empty schema descriptions.

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

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

The description opens with 'List landing pages,' a specific verb+resource statement. The resource type distinguishes it from sibling list tools like list_blogs and list_site_pages, and the filter list reinforces that this is a listing operation. No ambiguity remains about what this tool does.

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

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

There is no explicit statement about when to choose this tool over list_site_pages or get_page. The description implies usage via the list verb and filter parameters, but it does not state exclusions or direct the agent to an alternative for specific scenarios. This is clear context without explicit alternatives or 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?

With no annotations, the description carries the full behavioral disclosure burden. It clearly discloses the HubSpot API quirk that no general state filter exists and only published_only controls published/unpublished filtering, and it documents limit's range and default. Since this is a read-only listing operation, no destructive side-effect caveats are needed.

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, leading with the core action and then using an Args block where every line adds useful information. There is no filler, no restatement of schema titles, and no wasted words.

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

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

For a simple read-only list tool with three optional parameters, the description covers all parameters, their semantics, and an important API limitation. An output schema exists, so return-value details are not required, and the description is complete enough for an agent to call 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?

Schema description coverage is 0%, so the description must fully compensate, and it does. It explains that name_contains is a case-insensitive substring, clarifies the three-state behavior of published_only, and gives limit's valid range and default. Every parameter receives meaningful semantic guidance beyond its schema type.

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 'List marketing emails', a specific verb and resource combination that unambiguously identifies what the tool does. It also distinguishes itself from the many sibling list_* tools by naming the exact resource, and from get_marketing_email by using the 'list' verb.

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

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

The description provides no guidance on when to choose this tool over alternatives such as get_marketing_email, list_blog_posts, or other list_* siblings. It explains how the parameters behave but does not state prerequisites, exclusions, or explicit routing conditions, leaving usage to be inferred from the tool name.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only says the tool lists pages and shares filters with another tool, without mentioning pagination behavior, state semantics, language handling, or any other runtime behavior.

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

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

The description is extremely concise: two short sentences with no filler or duplication. It front-loads the core purpose and uses the sibling reference 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?

For a five-parameter list operation with no annotations, this description is underspecified. It does not explain what 'site pages' are, what filter values are accepted, or how this tool relates to list_landing_pages beyond filter similarity. The output schema reduces the need to describe return values, but the input behavior remains unclear.

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

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

Schema coverage is 0%, so the description must explain the five parameters, but it does not. The reference to list_landing_pages may indirectly help an agent that already understands that sibling, but it does not define limit, state, language, name_contains, or updated_after.

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 action and resource ('List site pages'), which is enough to know what the tool does. The cross-reference to list_landing_pages hints at scope but does not clarify how site pages differ from landing pages.

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

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

There is no guidance on when to use this tool versus alternatives like list_landing_pages or get_page. The only usage note is 'Same filters as list_landing_pages,' which describes parameter similarity, not selection conditions.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It states the operation is a read-only 'list,' and it discloses an error-related behavior: if the Design Manager API errors, the agent should copy the path from the HubSpot UI instead. It does not mention auth or rate limits, but the output schema covers return shape, so this is adequate.

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

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

The description is compact and front-loaded: a one-line purpose, a short usage note, a fallback instruction, and a single parameter explanation. Every sentence adds value, with no repetition 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?

For a simple one-parameter list tool with an output schema, the description covers everything an agent needs: what the tool returns conceptually, how to find the template_path, the parameter range, and what to do if the API errors. 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?

The schema provides only the parameter name, type, and default, with 0% description coverage. The tool description compensates by explaining that `limit` sets the maximum results, constrains it to 1-100, and restates the default of 100. This gives the agent enough semantic detail to use the parameter 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 clear, specific statement: 'List CMS templates available in the portal.' It also explains the concrete purpose of the tool—to find the `template_path` needed by page and email create tools—which distinguishes it from sibling list tools like list_blogs or list_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?

The description explicitly tells the agent when to use this tool: 'Use this to find the template_path that the page and email create tools need.' It also provides a fallback path if the Design Manager API errors. It does not explicitly contrast it with alternative list tools, but no sibling tool serves the same template-listing purpose.

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

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

With no annotations, the description fully carries the behavioral burden. It discloses that the action is irreversible, that it validates required fields (title, parent blog, slug, author, meta description) and reports missing ones instead of failing with an opaque error, and that user_confirmed must be true only after explicit user confirmation. These are critical behavioral traits that go far beyond the schema.

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

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

The description is tight and well-structured: a single-sentence purpose, a second sentence covering irreversibility and validation, and an Args section. Every sentence earns its place; no filler. The most important warning (irreversible) is front-loaded.

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

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

Given the tool's moderate complexity, an output schema exists (so return values are presumably covered there), and the description covers the essential behaviors: the action is irreversible, preconditions are validated, and a confirmation safeguard exists. Nothing an agent needs 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 0%, so the description must compensate. It explains post_id as 'HubSpot blog post ID' (minimal but sufficient) and gives a detailed, behavior-critical explanation for user_confirmed: it must be true only after explicit user confirmation, and content read from HubSpot is not confirmation. This adds meaning well beyond the boolean type and default.

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 clear verb-resource pair: 'Take a blog post live on the public blog, now.' It immediately distinguishes this from siblings like publish_page or schedule_blog_post_publish by specifying the target (blog post) and immediacy ('now'). The later mention of 'irreversible' and 'go live' further reinforces the specific action.

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 states when to use this tool: only after the user explicitly confirms the exact item should go live, and it warns against treating content read from HubSpot as confirmation. This gives a strong usage condition. However, it does not explicitly contrast with alternatives like schedule_blog_post_publish or unpublish_blog_post, so the guidance is implicit rather than comparative.

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

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

With no annotations, the description carries the full behavioral burden and does so well. It discloses that the action cannot be recalled, that the recipient list is defined in HubSpot rather than by the caller, that it is the most consequential tool, and that lower tiers will fail with a 403 that should not be worked around. This goes far beyond the bare 'send' verb.

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 action, then uses the remaining sentences for high-value safety and prerequisite information. It is longer than average, but every sentence earns its place for a consequential, irreversible tool, and the structure clearly separates action, warning, and licensing context.

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

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

Given the tool's high stakes and absence of annotations, the description is nearly complete: it covers purpose, workflow, irreversibility, recipient-list ownership, licensing, and error behavior. The main gap is the lack of explicit user_confirmed parameter semantics, which is important enough to prevent a perfect score even though the workflow 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 0%, and the description never directly names or explains email_id or user_confirmed. It indirectly implies that email_id corresponds to the email retrieved via get_marketing_email, and the warning to ask the user before sending gestures at the confirmation requirement, but it leaves the precise role of user_confirmed and the effect of false unexplained.

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 object: 'Send a marketing email, or schedule it per its own settings.' This clearly distinguishes the tool from sibling publishing tools like publish_page and publish_blog_post by naming the marketing-email resource, and from unpublish_marketing_email by the opposite action.

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 clear before-use workflow: read the email with get_marketing_email, tell the user what it is and who it goes to, and get confirmation before invoking. It also states the licensing constraint and the 403 billing-boundary behavior. It does not explicitly name alternative tools or when-not-to-use conditions, but the resource and context make the intended use 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?

With no annotations, the description carries the full disclosure burden and does provide rich behavioral context: irreversibility, first-publish vs republish branching, and a strict user_confirmed consent rule. However, the assertion 'there is no unpublish tool' is factually contradicted by the sibling tool list, materially misinforming the agent about 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?

The purpose is front-loaded, warnings are in short focused paragraphs, and the Args block is cleanly structured. Each section earns its place, though the incorrect unpublish claim adds misleading content that should have been verified against the actual tool list.

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 safety-critical publish action with an output schema present, the description covers confirmation semantics and state branching well. It is incomplete on routing guidance versus schedule_page_publish and contains the erroneous irreversibility claim, but the essential safety-critical behavior is well specified.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: page_id is identified as a HubSpot ID, page_type is mapped to its enum values, and user_confirmed receives a critical semantic rule — only True after explicit in-conversation confirmation, with HubSpot content reads explicitly excluded. This goes well beyond the schema's bare default flag.

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 opening line states a specific action — taking a landing or site page live now — with a clear verb and resource scope. It is distinguishable from siblings like schedule_page_publish and publish_blog_post by the resource (page) and immediacy ('now'), though it doesn't explicitly contrast itself with them.

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

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

It conveys immediate-publish intent and explains state-dependent branching, but never tells the agent when to prefer this over schedule_page_publish or when not to use it. The false claim that 'there is no unpublish tool' — despite unpublish_page being in the sibling list — actively misleads the agent about available 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?

No annotations are provided, so the description carries the full burden. It explicitly discloses that the operation is destructive and irreversible, and that it restores the live version. This is strong behavioral disclosure for a mutation tool, though it could add detail about what happens to the draft (e.g., whether it is deleted or overwritten) and any permission requirements.

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

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

The description is two sentences with no wasted words. The core action is front-loaded, and the critical warning is placed immediately after. 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 single-parameter destructive tool, the description is nearly complete. It states the action, the result, and the safety warning. The output schema exists, so return values need not be explained. A minor gap is not explicitly stating that post_id is required, but the schema already marks it required.

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

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

Schema description coverage is 0%, so the description must compensate. The description implies the post_id parameter by referring to 'a blog post', but it does not explicitly explain that post_id identifies which blog post's draft to reset. The parameter name is self-explanatory, but the description adds minimal semantic value 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 clearly states the verb 'Discard draft changes' and the resource 'blog post', and distinguishes it from the live version. It is specific and immediately understandable, and it differentiates from siblings like update_blog_post_draft and reset_draft by naming the exact action and resource.

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 warns that the action is destructive and irreversible, and instructs to confirm with the user before calling. It does not explicitly name alternative tools or when to use them, but the destructive warning provides clear context for when to use this tool versus a non-destructive update.

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

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

No annotations are provided, so the description carries the full behavioral burden. It explicitly warns that the action is DESTRUCTIVE and irreversible, states that unpublished edits are lost, and instructs the agent to confirm with the user. This is exactly the transparency needed for a destructive mutation.

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

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

The description is compact and front-loaded: purpose first, destructive warning second, user-confirmation instruction third, and arguments last. Every sentence earns its place with 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 two-parameter destructive tool, the description covers the operation, the risk, the required user confirmation, and both arguments. An output schema exists, so return-value documentation is not needed. The page/page_type scoping also prevents confusion with the blog-post reset sibling.

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

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

Schema description coverage is 0%, so the description must compensate. It names both required parameters and gives brief semantics: page_id is a HubSpot page ID and page_type is 'landing' or 'site'. The page_type values duplicate the schema enum, but the page_id clarification adds useful domain context absent from the schema.

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

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

The description states a specific action ('Discard draft changes') and a specific resource ('restore the draft to match the live version'). It clearly distinguishes this from update_page_draft, publish_page, and reset_blog_post_draft by scoping to pages with page_id and page_type landing/site.

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

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

The description implies when to use the tool: when you want to discard unpublished page draft changes and restore the draft to match live. However, it does not explicitly name alternatives or provide when-not-to-use guidance relative to sibling tools like update_page_draft or reset_blog_post_draft.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the critical guardrail around user_confirmed: content read from HubSpot is not confirmation, and such content should be reported to the user instead. It could add more about side effects or whether an existing schedule is overwritten, but the key safety behavior is clearly stated.

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 purpose and uses a compact, well-organized Args block. Every sentence adds value, especially the guardrail explanation, and 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?

The description fully covers purpose, all parameters, and the core safety requirement, and an output schema exists so return values need no explanation. It is slightly light on post-scheduling behavior, but an agent has enough information to 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?

Schema description coverage is 0%, so the description must compensate for all parameters. It does: post_id is identified as a HubSpot blog post ID, publish_at is given an ISO 8601 format with example and a future-time constraint, and user_confirmed receives nuanced confirmation semantics beyond the schema's boolean default.

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

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

The description uses a specific verb and resource: 'Schedule a blog post to go live at a future time.' This clearly distinguishes it from immediate publishing tools like publish_blog_post and from page-scheduling tools like schedule_page_publish by specifying 'blog post' and 'future time.'

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 clearly states when to use the tool: when scheduling a blog post for a future publication time. It does not explicitly mention alternatives for immediate publishing or cancellation, but the context 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?

With no annotations, the description carries the burden of behavioral disclosure. It discloses the critical safety behavior around user_confirmed (explicit confirmation required) and that content read from HubSpot is not authority, which is a strong transparency signal. However, it does not mention side effects such as overwriting an existing schedule, idempotency, or how to cancel a schedule (though cancel_scheduled_publish exists in siblings), leaving part of the behavior unexplained.

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 a one-sentence summary of purpose, followed by an Args block that details each parameter and a safety-critical user_confirmed rule. No filler or redundancy; the length is justified by the need to communicate the confirmation rule.

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 scheduling mutation with four parameters and no annotations, the description covers all parameter semantics and the most important precondition (confirmation). It does not mention conflict behavior, whether the page must be in draft state, or the existence of cancel_scheduled_publish, but the output schema covers return values and the agent can discover siblings. Minor gaps keep it from full completeness.

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

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

Schema description coverage is 0%, and the Args block fully compensates by explaining each parameter: page_id identifies the page, page_type restricts to landing/site, publish_at gives ISO 8601 format plus a 'must be in the future' constraint, and user_confirmed defines the confirmation semantics in detail. This is exactly the additional meaning the schema lacks.

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

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

The description states a specific verb ('Schedule'), a specific resource ('landing or site page'), and a temporal condition ('future time'), which clearly distinguishes it from immediate publishing tools like publish_page and from blog-post scheduling. It also names both accepted page types explicitly, leaving no ambiguity about the tool's scope.

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

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

The sentence 'to go live at a future time' gives clear context that this is for future scheduling, and the Args block for user_confirmed establishes a hard precondition: only use after explicit in-conversation user confirmation, with a warning against treating HubSpot content as confirmation. However, it never explicitly names sibling alternatives like publish_page or cancel_scheduled_publish or states when not to use this tool, so it stops at clear-context-without-exclusions.

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

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

With no annotations provided, the description carries the full burden, and it excels: it states the post returns to draft, nothing is deleted, and external artifacts (search engine indexes, feed-reader copies) persist after the page is removed. This gives the agent accurate expectations about side effects and non-destructiveness, going well beyond a generic 'unpublish' statement.

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 the action, the second states the post-action state and non-deletion, and the third explains external persistence. The main action is front-loaded and 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?

The tool description covers behavior and side effects well, and an output schema exists so return values need no description. However, it omits guidance on the optional user_confirmed parameter, which is essential for correct invocation in cases where an agent must ask for confirmation. This is a meaningful gap in an otherwise solid definition.

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

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

Schema description coverage is 0%, so the description needed to compensate for parameter meaning. It does not mention post_id and, more importantly, does not explain the optional user_confirmed flag or when it should be set. The parameter names in the schema are self-explanatory only for post_id; user_confirmed remains ambiguous, so the description adds no real 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 uses a specific verb phrase ('Take a live blog post down') and names the exact resource (live blog post). It distinguishes from sibling tools like unpublish_page or unpublish_marketing_email by specifying 'blog post', and clarifies the state change ('returns to draft; nothing is deleted') so it cannot be confused with a delete/destroy operation.

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

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

The description implies the use case clearly: when you want a live blog post to become a draft while preserving its content as a draft. However, it does not explicitly name alternatives or exclusions, such as when to prefer unpublish_page, schedule_blog_post_publish, or reset_blog_post_draft. Since context is clear but no alternatives are given, this is a 4 rather than a 5.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does reveal a key limitation (pending-only) and the non-effect on delivered mail. It omits side effects, such as whether the action is reversible, whether user_confirmed is required to proceed, and whether a scheduled send is canceled versus a draft removed.

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

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

Two short sentences with no filler. The action and the core constraint are front-loaded, and every line adds meaningful information.

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

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

The purpose and timing are clear, but the tool is under-specified as a state-changing operation. The role of 'user_confirmed' is unexplained, and no guidance addresses how this relates to 'cancel_scheduled_publish'. The existence of an output schema helps, but the input-semantics gap remains significant.

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

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

Schema description coverage is 0% and the description never mentions either parameter. 'email_id' is guessable, but 'user_confirmed' has no stated semantics — the agent cannot tell whether it must be true, what it confirms, or what happens when it is false.

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

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

The description uses a concrete verb ('Withdraw') on a specific resource ('marketing email') and clearly bounds the action to emails that have not yet gone out. It distinguishes this tool from publishing tools and broader unpublish siblings, though it does not explicitly contrast it with the similarly named 'cancel_scheduled_publish'.

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 is explicit about when the tool is useful: only while the send is still pending. It also gives a clear when-not condition by noting that delivered emails stay delivered. However, it names no alternative or fallback, so it does not fully earn a 5.

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

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

With no annotations, the description carries the full burden and does so thoroughly. It discloses that the page becomes a draft, nothing is deleted, the URL stops serving immediately, inbound links break, and the legacy endpoint should be verified in the UI.

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

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

The key state change is front-loaded, followed by user-impact warnings, then the technical caveat. Every sentence contributes either to correct invocation, user communication, or post-call verification, with no filler.

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

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

The description is nearly complete for a state-changing tool: it gives purpose, side effects, user-safety guidance, and a verification step. It loses a point only because the parameter semantics are not fully covered and the legacy-endpoint note is not expanded into concrete handling.

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

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

Schema description coverage is 0%, so the description needed to explain page_id, page_type, and user_confirmed. It implies user confirmation ('Say that to the user before asking') but never connects it to the user_confirmed parameter or explains how page_type landing vs site is determined.

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 opens with a specific verb and resource ('Take a live page down') and states the precise outcome ('returns to draft; nothing is deleted'). It also clearly distinguishes unpublish_page from sibling publish/schedule tools by focusing on taking a live page offline.

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 actionable context: warn the user about immediate URL breakage and ask before calling, and check whether a redirect is wanted instead. It does not explicitly name sibling alternatives or state when not to use the tool, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses the critical safety behavior (published version untouched) and the refusal mechanism for publish/schedule fields, including the `rejected_fields` output. This goes beyond basic mutation; it sets expectations for side effects and restrictions.

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 tight and well-organized: a one-sentence purpose, an Args list, and a note on rejected fields. No filler. The safety guarantee is front-loaded, and the parameter list is necessary because the schema lacks descriptions. Every sentence adds value.

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 the key aspects: what it does, what parameters are allowed, and what constitutes invalid input. It does not cover error handling or prerequisite conditions (e.g., draft existence), but those are less critical given the output schema and the tool's simple contract.

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

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

The input schema provides zero description coverage for parameters. The description compensates by enumerating valid `fields` keys (name, htmlTitle, slug, postBody, etc.) and explaining `post_id` as a HubSpot blog post ID. This gives agents concrete guidance on allowed field names, which the schema alone does not provide.

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 'Patch a blog post's DRAFT' – a specific verb, resource, and state – and immediately differentiates it from publishing/scheduling tools by stating 'The published version is never touched.' This clearly distinguishes it from siblings like publish_blog_post and schedule_blog_post_publish.

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 clearly implies the tool is for draft updates only and reinforces this with 'Fields that could publish or schedule the post are refused.' While it does not name alternative tools explicitly, the behavioral restriction effectively routes agents away from publish/schedule operations and toward the appropriate sibling.

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?

There are no annotations, so the description bears the burden of behavioral disclosure. It does disclose a meaningful behavioral trait: updates are partial and non-destructive to omitted keys. It does not mention side effects, permission requirements, validation behavior, or whether the operation is reversible, but the partial-update disclosure is a genuine behavioral signal.

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

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

The description is two short sentences with no filler. The core action is front-loaded in 'Update campaign properties,' and the critical partial-update behavior immediately follows. 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 mutation tool with no annotations and zero schema description coverage, the description is too sparse to be fully actionable. It omits what campaign properties are supported, whether any values are validated or transformed, and any prerequisites for updating a campaign. An output schema exists, so return format is less of a concern, but the input-side knowledge gap remains significant.

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

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

Schema description coverage is 0%, so the description must compensate for the input schema's empty `properties` object and vague `campaign_id` parameter. The description adds some meaning by indicating that the `properties` object contains keys to update, but it does not explain what valid campaign property keys exist, nested structures, or how campaign_id should be formatted. This leaves significant semantic gaps.

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 'Update' and resource 'campaign properties,' distinguishing it from read-only and create siblings like get_campaign and create_campaign. The added phrase 'Only the keys you pass change' clarifies the partial-update semantics beyond a generic 'update campaign.' It is not quite a 5 because it does not explicitly contrast with any sibling by name.

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

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

The phrase 'Only the keys you pass change' implies when to use this tool: update an existing campaign by passing only the properties to alter, leaving others untouched. However, there is no explicit guidance about prerequisites, such as the campaign needing to exist, or when to prefer create_campaign or other sibling tools. The usage context is implied rather than stated.

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

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

With no annotations provided, the description must disclose behavior itself. It does so by signaling partial-update semantics with 'Patch' and, more importantly, warning that fieldGroups must be sent as the full modified tree rather than a sparse patch. This is a meaningful behavioral nuance beyond the tool name and 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?

The description is compact and well-structured: a one-line summary, a terse argument list, and a single workflow sentence. There is no filler or repetition of schema data.

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 open fields schema, the description provides the allowed keys and the critical fieldGroups workflow, and it points to get_form as a prerequisite. The output schema covers return values, so omitting them from the description is acceptable. A small gap is the lack of authentication or side-effect context, but the tool is still callable correctly with the information given.

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

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

Schema description coverage is 0%, so the description must compensate. It does: form_id is explained as 'HubSpot form ID', and the free-form fields object is constrained to 'any of name, fieldGroups, configuration, displayOptions, legalConsentOptions.' This adds meaning the schema's additionalProperties object lacks.

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 begins with 'Patch a form', naming a specific verb and resource, then lists the editable categories. This makes it clearly distinct from sibling tools like create_form, duplicate_form, and get_form without being tautological.

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 a concrete workflow: 'To change the field set, call get_form first, modify the returned fieldGroups, and pass the whole tree back here.' This gives clear context for an important use case. It does not explicitly mention when not to use the tool or name alternatives, but the form-specific resource and patch semantics make the intended usage reasonably 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?

With no annotations provided, the description carries the full behavioral burden. It discloses key safety behaviors: published versions are never touched, and publish/send attempts are refused and reported in 'rejected_fields.' This is meaningful, though it omits details such as permissions, reversibility, or rate limits.

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

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

The description is compact and front-loaded with the core behavior. The Args section is clear, and every sentence earns its place—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?

Given the output schema is present and the tool has only two parameters, the description covers the essential behavior, accepted fields, and refusal behavior. It could additionally state whether a draft must already exist or how errors are returned beyond 'rejected_fields,' but these are minor gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It defines email_id as 'HubSpot email ID' and lists the allowed keys for fields: name, subject, language, content, from, to, subscriptionDetails, businessUnitId, campaign. It does not give value formats or nested object shapes for fields, but the allowed-key list adds essential meaning beyond the unconstrained object 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: 'Patch a marketing email's DRAFT.' It also draws a clear boundary with 'The published version is never touched,' which differentiates it from publish/unpublish siblings and makes the tool's scope immediately obvious.

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 clearly indicates this tool is for modifying drafts, not published versions, and states that anything attempting to publish or send will be refused. It does not explicitly name alternatives like 'use publish_marketing_email to publish,' but the draft/published distinction provides sufficient context for correct selection.

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

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

With no annotations, the description carries the full behavioral burden. It discloses major behaviors: it never touches the published version, refuses publish/schedule-capable fields and reports them via rejected_fields, requires include_content=True fetching before layoutSections/widgets writes, and explains the consequences of rich-text HTML misuse. This is exemplary transparency.

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 parameter list, then moves into necessary, high-impact behavioral warnings. Every paragraph covers a scenario that could cause a wrong or destructive call, so the length is justified.

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

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

For a mutation tool with nested objects, no annotations, and no schema-level parameter documentation, the description covers the full calling context: what fields are allowed, what is rejected, how to safely edit content trees, and what HTML is permitted. The output schema presumably covers return details, so the description need not repeat them.

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

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

Schema coverage is 0%, so the description must define parameters entirely. It explains page_id as a HubSpot page ID, page_type with valid values, and fields with a concrete list plus critical guidance on layoutSections/widgets and rejected_fields. The free-form fields object is made meaningful.

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 'Patch a page's DRAFT' and immediately clarifies 'The published version is never touched.' This is a specific verb plus resource that clearly distinguishes draft editing from the sibling publish_page and schedule_page_publish 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 clearly describes the resource type and the fields that can be set, and it implies this is for editing an existing draft rather than creating or publishing. It does not explicitly name sibling alternatives such as create_landing_page_draft or publish_page, so it stops short of full exclusion guidance.

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