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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does this well by warning that created activities are permanently locked, cannot be edited in Target UI, and require later activation via updateActivityState. It also documents auto-filled defaults and the required state value.

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 and well-sectioned with warnings, mandatory steps, and a structured payload reference. However, it is very long and repeats the same core guidance—'do not use for normal workflows, use createOffer instead'—in the critical warning, conditions list, mandatory steps, recommended alternative, and final reminder.

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 having no annotations and no output schema, the description is complete enough for safe invocation: it covers prerequisites, required user confirmations, default values, required fields, and the full nested payload structure. An agent can construct a valid request and understand the irreversible consequences.

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?

Although the input schema has 100% description coverage, its descriptions are shallow: 'activity' is simply 'Full A/B Test activity definition object'. The tool description compensates with a complete annotated payload reference covering field types, defaults, enums, required vs optional fields, and relationships among locations, options, experiences, and metrics.

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 makes clear that this tool creates A/B Test activities programmatically and positions it against the normal createOffer workflow. It also defines the tool's unique niche: bulk or CI/CD-driven activity creation where the normal UI-based flow is not appropriate.

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 to use this tool, when not to use it, and which alternative to prefer. It mandates specific user-confirmation steps before invocation and names createOffer as the default workflow, leaving essentially no ambiguity about tool selection.

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

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

With no annotations, the description carries the full burden and it goes far beyond a generic 'create' statement: it discloses permanent UI lock, mandatory preview, responsive-testing expectations, code-generation constraints, and conversion-tracking requirements. This gives the agent a precise model of the tool's side effects and constraints.

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 content is well-structured with headings, numbered confirmations, and examples, and the critical warning is front-loaded. However, it is extremely long and contains repetition (three nearly identical confirmation steps, responsive-testing flow described twice), so it is not a concise or tightly edited description.

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 high-stakes creation tool with no output schema and no annotations, this description is exceptionally complete: it covers preconditions, alternative workflows, code rules, preview procedures, viewport testing, and conversion tracking. An agent has everything needed to decide whether and how 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 coverage is already 100% for the five parameters, so the baseline is 3; the description earns an extra point by deeply specifying the modifications parameter: no preview indicator, ES5 only, at- prefixed classes, dataLayer events, and responsive requirements. It adds little on name/url/priority/audienceIds, but those are adequately covered by 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 makes clear the tool creates Adobe Target activities from generated modification code, and it repeatedly positions it as the bulk/locked-activity creation path versus the createOffer workflow. However, it never crisply states 'creates an XT activity from modification JavaScript' up front and does not contrast itself with createABActivity, so differentiation from that sibling is left to inference.

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 to use this tool: only for 10+ bulk activities or CI/CD, only after three user confirmations, and with createOffer as the 99% alternative. It also gives a recommended alternative workflow, so an agent has clear routing between this tool and its 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 provided, the description carries the full burden of behavioral disclosure. It only says 'create', offering no information about persistence, idempotency, duplicate handling, validation of targetRule, permissions, or response 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 a single sentence with no wasted words, but it is under-specified and duplicates the tool name. It does not earn its place because it contributes no information beyond what the name already conveys.

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

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

There is no output schema, no annotations, a nested targetRule object, and a long list of sibling tools. The description leaves the agent with no guidance on targetRule shape, return values, or invocation context, making it inadequate for a tool with this complexity.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the description adds no parameter-level meaning. The description does not clarify how targetRule should be structured, but that is not its responsibility given complete schema coverage.

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 'Create a new audience' restates the tool name exactly and provides no additional detail about what creating an audience entails. It is not misleading, but it is tautological and does not help distinguish this operation from other create-type 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 on when to use this tool versus alternatives such as listAudiences or createABActivity. No prerequisites, exclusions, or practical context 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 present, so the description carries the full burden, and it delivers: it warns 'THIS TOOL CREATES OFFERS, NOT ACTIVITIES', explains JSON offers are not auto-applied to the page and must be retrieved by the application, requires showing JSON to the user for approval before creation, and includes content rules like 'NEVER include emojis'. It also discloses that API-created offers can be edited in the Target UI, giving agents a clear mental model of side effects and constraints.

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 long and repetitive. Concepts like control vs. variant, the A/B workflow, and 'JSON offers are not auto-applied' appear multiple times across sections (e.g., 'CONTROL VS VARIANT GUIDANCE', 'WORKFLOW', 'HOW JSON OFFERS WORK'). While it uses clear headings, it is not appropriately sized and many sentences do not earn their place; an agent would have to wade through a massive prompt to extract the core 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 description is thorough about the end-to-end workflow, including showing JSON to the user, creating one offer per variation, providing offer IDs, and suggesting next steps in the Target UI. It covers application integration patterns. The main gap is that it never explicitly states the tool's return object shape (e.g., the JSON response containing the offer ID), only implying it via 'Use the returned offer ID'. Given no output schema exists, an explicit return format statement would make it complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful extra semantics: naming convention '[Test Name] - [Variation Name]', the rule that content must be a valid JSON object, multiple worked examples of content, and clarification that workspace is optional and falls back to TARGET_WORKSPACE_ID. This goes beyond the schema's terse property 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 'SPECIALIZED TOOL - FOR SPAs, SERVER-SIDE, MOBILE, AND HEADLESS' and 'Create JSON offers for applications that consume structured data', clearly stating the verb, resource, and audience. It explicitly differentiates from the sibling createOffer by saying 'DO NOT USE THIS AS THE DEFAULT - Use createOffer (HTML) for most use cases!' and clarifies it creates offers, not activities.

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 extensive when-to-use and when-not-to-use guidance: 'WHEN TO USE THIS TOOL' lists specific triggers (SPA, React, server-side, mobile, etc.), while 'WHEN NOT TO USE' says to use createOffer for HTML/DOM changes. It even includes an ambiguity-resolution script asking whether the user's content will be consumed as JSON or modify the page, with a default fallback to createOffer.

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 a lot: it warns that CSS cannot be in standalone <style> tags, mandates ES5 compatibility, requires IIFE wrapping to avoid variable collisions, and instructs preview-before-create flow. It also discloses that offers created via API can be edited in Target UI. Minor deduction because the description is exceptionally long and speculative (includes fictional example output IDs), but the behavioral guidance itself is substantive and not contradicted by any annotation.

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 repetitive and over-sized for an MCP tool definition. The same workflow steps are presented multiple times (Steps 1-4 appear twice with different numbering; Control vs Variant guidance repeats the A/B and XT patterns; the 'NEXT STEPS IN ADOBE TARGET UI' instructions appear twice almost verbatim; code generation rules cover the same points in several places). While front-loaded with the primary purpose, the massive duplication and example-heavy length actively reduce scannability. This is not conciseness; it is redundancy.

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

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

For a 3-parameter tool with no output schema and no annotations, the description covers the full lifecycle: when to extract the page, how to generate a preview, how to create offers per variation, what to tell the user afterward, and code quality constraints. It even handles edge cases like expired auth tokens, unclear SPA vs HTML requests, and template search. An agent can call this tool correctly and complete the surrounding workflow without external knowledge.

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

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

Schema description coverage is 100% (name, content, workspace are each described). The description adds significant meaning for the 'content' parameter: full HTML offer structure rules, CSS injection instructions, ES5 constraints, IIFE requirement, at- prefix rules, and code examples. This goes well beyond the schema's short parameter descriptions. Workspace behavior is also clarified in the schema itself. A 4 is appropriate since the description genuinely complements the schema without being able to add much to 'name'.

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

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

The description opens with 'PRIMARY DEFAULT WORKFLOW - USE THIS FOR 95%+ OF ALL USE CASES' and explicitly states this tool creates HTML/CSS/JavaScript offers for DOM modifications and visual changes. It clearly names createJsonOffer as the alternative for JSON/SPA cases, and consistently distinguishes 'creates offers, not activities' by explaining activity types map to offer creation. This is a specific verb + resource + scope, sharply differentiated from siblings.

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

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

The description contains an extensive 'WHEN TO USE THIS TOOL' and 'WHEN NOT TO USE (Use createJsonOffer instead)' section with explicit conditions, including an 'IF UNCLEAR WHICH TO USE' fallback question and default-to-this-tool guidance. It also explains when NOT to create activities programmatically and when to skip page extraction. This is explicit when/when-not/alternative coverage beyond any typical description.

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

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

With no annotations, the description carries the behavioral disclosure burden. It does substantial work: it states the tool only creates new custom tokens, documents token types and examples, and calls out the important limitation that profile scripts cannot be created via the Admin API. It does not mention failure modes, permissions, or response behavior, which prevents a higher score.

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 well-structured with headings, numbered workflows, and bullet lists, and the key purpose is front-loaded in the first sentence. It earns most of its length through token-type examples and limitations, though some redundancy exists between the 'IMPORTANT LIMITATION' and 'WORKFLOW FOR SCRIPT TOKENS' sections.

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 high-complexity creation tool with no output schema and no annotations, the description is largely complete: it supplies required examples, preconditions, alternative workflows, and UI fallbacks. The main gaps are the meaning of the optional id field and any expectation about what the API returns after creation.

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 already 100%, but the description goes further by explaining each BUILT_IN/ACTIVITY/GEO/CRS/MBOX/SCRIPT type with concrete token examples and the mbox/profile-script implementation caveats. The optional 'id' parameter is not explained beyond the schema's 'Response token ID (optional)', so the description does not fully clarify every parameter's role.

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

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

The description opens with 'Create a NEW CUSTOM response token' and states the purpose: 'to include data in Adobe Target activity responses.' It clearly separates this tool from listResponseTokens and from the Target UI by emphasizing it creates new custom tokens only, so an agent can distinguish it from siblings.

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

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

The description gives explicit when-to-use guidance: run listResponseTokens first, activate existing deletable:false tokens in the Target UI, and only use this tool for tokens that do not yet exist. It also explains the profile-script case where the script must first be created in the UI, providing clear routing between API and UI workflows.

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. It discloses important behavioral traits: output is ES5-compatible, code includes defensive checks, no polling/setInterval is used, firing conditions are configurable, and defaults are specified. This gives the agent a realistic expectation of the generated behavior and constraints.

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

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

The description is well-structured with clear headings, but it is quite verbose and contains redundancy. Firing condition options are repeated in multiple sections, and the default 'always' is emphasized repeatedly. A more condensed version would retain clarity while removing repetition.

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

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

For a complex code-generation tool with 9 parameters and no output schema, the description is remarkably complete. It covers supported tag managers, workflow steps, firing condition options, required parameters, code constraints, and important edge-case guidance. An agent has enough context to invoke it correctly.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaningful context beyond the schema: how tag manager is selected, which parameters to pass in the workflow, firing condition semantics, and guidance like 'Attach to the most specific selector possible.' This enriches parameter understanding.

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: 'Generate ES5-compatible event tracking code for Adobe Target activity conversions.' It clearly distinguishes this tool from siblings like generatePreviewScript by focusing on conversion event tracking across multiple tag managers.

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

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

The description provides explicit usage context: 'When creating or modifying Target experiences with conversion elements (buttons, links, forms), use this tool to generate click tracking code.' It also gives a detailed workflow for when to invoke the tool and what questions to ask. However, it does not explicitly mention alternatives or when not to use 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 must carry the behavioral burden. It discloses that the tool produces a script rather than directly modifying the page, and that the injection is done via Chrome DevTools MCP evaluate_script. However, it doesn't mention return format, potential errors, or any edge-case behavior, leaving some 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 purpose is front-loaded, and the numbered workflow is well organized for a multi-step tool. It is longer than minimal but every step serves a practical role. Some redundancy exists at the end ('This approach uses Chrome DevTools MCP and execute_script'), but it doesn't detract significantly.

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 no output schema and no annotations, the description is unusually complete: it provides the full interaction flow, explicit timeout guidance, page-loading instructions, and an approval gate. An agent would know exactly how to invoke and sequence this tool end-to-end.

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

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

Schema coverage is 100%, so the schema already documents all three parameters. The description adds value by contextualizing them: url is tied to navigate_to loading, modifications are tied to user-visible selector changes and later injection, and description is tied to the preview explanation. This goes beyond the schema's basic field descriptions.

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

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

The description uses a specific verb ('Generate') and resource ('preview script for Chrome DevTools MCP') and clearly states the purpose: inject modifications into a live page. The workflow line 'Wait for user approval before creating the activity' distinguishes it from the sibling createActivityFromModifications, even though that sibling isn't named.

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

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

A numbered 7-step workflow gives explicit context for when to call the tool, what to do before, and how to follow up with navigate_to and evaluate_script. It does not explicitly name alternative tools or state when not to use it, but the sequencing is clear enough to guide tool selection.

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

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

No annotations are provided, so the description carries the burden. 'Get details' implies a read-only lookup, but the description does not disclose response shape, error behavior, permissions, or any side-effect absence beyond the verb itself.

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

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

A single clear sentence with no redundancy. It is appropriately sized for a simple get-by-id tool.

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

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

For a one-parameter read tool, this is minimally adequate, but the description is vague about what 'details' will be returned and there is no output schema or annotations to fill that gap. Failure behavior and response format are also unaddressed.

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

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

There is only one parameter and the schema already describes it as 'Activity ID' with 100% coverage. The description adds no additional meaning beyond emphasizing that the activity is specific, so the baseline of 3 applies.

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

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

The description clearly states the action ('Get details') and the resource ('A/B Test activity'), with 'specific' indicating singular retrieval by ID. It is distinguishable from list/create/update siblings, though it does not explicitly name an alternative.

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

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

The wording 'specific A/B Test activity' implies use when a known activity ID exists rather than listing all activities. However, there is no explicit guidance about when not to use it or which sibling tool might be more appropriate.

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 only says the tool 'gets' report data and includes metrics, but it does not mention authentication needs, read-only safety, default date-range behavior, pagination, errors, or whether the report is generated synchronously.

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, well-structured sentence with no wasted words. The core action and resource are front-loaded, and the additional content detail is relevant and concise.

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 simple two-parameter schema, the description is mostly adequate for basic invocation, but it lacks output-schema details and does not clarify what happens when reportInterval is omitted or how the returned report data is structured. The absence of annotations and output schema makes this a minimum-viable but not fully complete 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?

The input schema already describes both parameters clearly: id is the Activity ID and reportInterval is an optional ISO 8601 date range. The description adds no additional parameter semantics, so the baseline score of 3 applies.

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

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

The description clearly states a specific verb ('Get'), a specific resource ('orders report data'), and the target type ('A/B Test activity'). It also names high-level contents ('conversion metrics and order information'), which helps distinguish it from sibling report tools like getXTOrdersReport or getABPerformanceReport.

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 about when to use this tool versus the many sibling report tools, nor are there any exclusions or alternative suggestions. The agent is left to infer usage solely from the name and description.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'Get' strongly implies a read-only operation, and the mention of metrics, conversions, and visitor data gives some sense of the response content. However, it does not disclose output format, pagination, report generation behavior, or other operational details.

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 sentence that front-loads the verb and resource, then adds useful high-level content expectations. Every word contributes 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?

The tool is relatively simple with only two parameters, and schema coverage is complete, but there is no output schema and no annotation context. The description gives a high-level idea of the report contents but does not fully specify the return structure or how reportInterval influences the response, leaving moderate 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 100%, so id and reportInterval are already well documented in the input schema. The description does not add parameter-level meaning beyond what the schema provides; the baseline score of 3 is appropriate.

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

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

The description names a specific verb ('Get'), a specific resource ('performance report for an A/B Test activity'), and explicitly lists content areas (metrics, conversions, visitor data). This clearly distinguishes it from sibling report tools like getXTPerformanceReport and getABOrdersReport.

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 about when to choose this tool over sibling alternatives such as getABOrdersReport, getActivityInsights, or the XT/APT report tools. The description implies use for A/B performance reporting, but it does not state exclusions or specific 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 provided, the description carries the full burden. It discloses the behavioral promise (search, compare all experiences, return insights/recommendations) and the partial-match name lookup behavior. But it does not state whether the operation is read-only, what the response structure contains, or constraints like data freshness or rate limits — notable gaps since no annotations backstop the safety profile.

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

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

Two tight sentences with zero filler. The core function is front-loaded first, and the key access requirement ('No activity ID needed') follows immediately. 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 3-param tool with no output schema and no annotations, the description conveys the core function and the single required input adequately. However, it does not position itself against the five sibling report tools (getABPerformanceReport, getXTPerformanceReport, getAPTPerformanceReport, etc.) or indicate which report types it spans, and the absence of any return-shape hints leaves an agent without an output schema to guess what 'insights and recommendations' look like.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds mild value by framing activityName as a search key supporting partial matches ('Search for an activity by name') and by clarifying that no ID parameter is needed. It adds nothing beyond the schema for reportInterval or qaUrl, which are already well documented 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 specific verb and resource ('Search for an activity by name') plus a concrete output ('performance comparison of all experiences with insights and recommendations'). The phrase 'No activity ID needed - just provide the activity name' partially distinguishes it from ID-keyed report siblings like getABPerformanceReport, but it never explicitly names or contrasts a sibling tool.

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

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

'No activity ID needed - just provide the activity name' implies the tool is for name-based lookup, which indirectly signals that alternative ID-required report tools exist among the siblings. However, it never explicitly states when not to use this tool or names the alternatives (e.g., getABPerformanceReport, getXTPerformanceReport), leaving that inference to the agent.

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. 'Get' implies a read-only report operation, and the listed data categories indicate what the report contains. However, it does not disclose any caveats such as permissions, report generation constraints, or behavior of the optional date range 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 a single, front-loaded sentence with no filler. Every phrase adds useful information: the action, the report type, the activity type, and the report contents.

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 retrieval tool with two documented parameters, the description covers the core purpose and high-level report contents. Still, the absence of an output schema and annotations means it would benefit from noting that this is a read-only operation or from pointing to sibling tools for other report types.

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

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

Schema description coverage is 100%, and the descriptions for id and reportInterval already explain their purpose and format. The tool description adds no additional parameter meaning, so the baseline of 3 is appropriate.

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

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

The description clearly states the verb 'Get' and the specific resource 'performance report for an Automated Personalization Test (APT) activity'. Specifying APT distinguishes it from sibling report tools such as getABPerformanceReport and getXTPerformanceReport, and the data categories (metrics, conversions, visitor data) further clarify 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 qualified activity type implies this tool is for APT performance reports, but it does not explicitly say when to use it instead of related report tools or when not to use it. No alternatives are named, leaving the agent to infer selection criteria from the activity type.

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 transparency burden. It does disclose that this is a read operation via 'Retrieve' and gives a sense of the returned content categories. However, it does not mention side effects, permissions, error behavior, or whether the response is complete or partial. For a simple parameterless getter, this is adequate but not rich.

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 sentence that front-loads the core action and resource, then lists useful specifics. Every part contributes meaning; even the trailing 'and other AT.js library settings' usefully signals that the list is non-exhaustive. It is compact without sacrificing clarity.

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

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

For a parameterless read tool, the description provides a reasonable overview of what is returned, but it stops short of being fully complete. There is no output schema, so the description carries the burden of explaining the return value; it names several settings but remains vague about the full shape or behavior. Additionally, the broad sibling context offers no guidance to reduce ambiguity.

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

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

The tool has zero parameters and the schema is empty, so there are no parameter semantics to document. The baseline for no parameters is 4, and the description correctly focuses on the output content rather than inputs. No additional parameter-related explanation is needed.

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

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

The description uses a specific verb 'Retrieve' with a concrete resource, 'AT.js settings', and enumerates key included fields (client code, decisioning method, timeout, global mbox configuration). This clearly separates it from the similarly named sibling getAtjsVersions, but it does not explicitly call out that distinction. Overall purpose is clear and actionable.

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 getAtjsVersions or getMbox. The context signals include many sibling tools that could overlap in the AT.js domain, but the description does not provide any 'use this when...' or 'for versions use getAtjsVersions' direction. Usage is only implied by the tool's name and the verb.

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

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

The description frames the operation as read-only by using 'Retrieve list', which is useful given that no annotations are provided. However, it does not disclose details such as ordering, whether deprecated or all versions are included, or response shape, which would be more transparent for a tool with no output schema.

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

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

The description is a single, front-loaded sentence that starts with the verb and states the resource directly. Every word earns its place, and there is no redundant or filler content.

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

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

For a no-parameter, read-only list tool, the description is mostly complete: it states what is returned and the target resource. It could be slightly stronger by noting the relationship to AT.js settings or the expected return format, but nothing essential blocks 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 parameters and the schema is empty, so there is no parameter meaning for the description to add. The baseline for zero-parameter tools is 4, and the description appropriately needs no additional parameter detail.

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

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

The description clearly states a specific action ('Retrieve list') and a distinct resource ('available AT.js versions'). This uniquely identifies the tool among siblings, especially against the similar getAtjsSettings, by naming a different resource type.

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

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

There is no explicit guidance on when to use this tool versus alternatives, and no alternative is mentioned. However, the resource name and description make the usage reasonably implied: an agent should use this when it needs to list available AT.js versions.

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 present, the description carries the full burden of behavioral disclosure. It adds meaningful context: results are in descending order by time, only latest 100 revisions are retained (including CREATE and DELETE), admin page entities record only concrete updates, and authorizedHosts requires using client ID as entity ID. This goes well beyond a basic read operation description.

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 concise and front-loaded with the primary action, followed by a compact bulleted NOTE section. Every sentence carries necessary information, and the structure is easy to scan for an agent.

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 read operation with no output schema, the description covers purpose, ordering, data retention, special entity behaviors, and ID mapping. It lacks mention of return format or error cases, but these are not critical given the simplicity of the tool and its clear audit-history intent.

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?

Input schema coverage is 100%, with both parameters having descriptions that capture the same meaning (entity type and entity ID). The description reinforces the authorizedHosts client-ID rule already present in the schema but does not add substantial new parameter-level details beyond that. Baseline of 3 is appropriate.

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

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

The description clearly states a specific verb ('Get'), resource ('all revisions/audit history'), and scope ('of a specific entity by ID, in descending order by time'). It is easy to understand what the tool does, but it does not explicitly differentiate itself from the sibling tool getRevisions, leaving some ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives like getRevisions or other list/fetch tools. The NOTE section gives useful caveats and parameter hints, but it does not state any selection criteria, exclusions, or preferred scenarios for using 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?

With no annotations provided, the description carries the behavioral disclosure burden. It conveys the read-only nature through 'Get' and lists the main returned fields, which is helpful. However, it does not mention error behavior, authorization needs, or the exact response structure, leaving some gaps.

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 front-loaded sentence that leads with the action and resource, then lists the relevant data points. Every word earns its place, with no redundancy or filler.

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

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

For a one-parameter read tool with no output schema, the description adequately covers the input and the key returned fields. The word 'including' implies there may be additional unspecified fields, and the exact JSON shape is not given, but this is a minor gap for such a simple 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 100%, with mboxName already documented as the mbox name with concrete examples. The description's 'by name' adds no new parameter-level meaning beyond what the schema provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Get details'), a precise resource ('a specific mbox by name'), and enumerates the returned content (location ID, name, associated audience IDs). This clearly distinguishes it from siblings like listProperties, getABActivity, and listActivities, which target 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 makes the usage context clear: call this tool when you need details of a single named mbox. It does not explicitly name alternatives or exclusion conditions, but among the sibling tools, none other targets a specific mbox, so the context 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?

There are no annotations, so the description carries the full behavioral disclosure burden. It does say the tool 'get[s] current page structure' and is the 'FIRST STEP', implying a read-only extraction operation. However, it never explicitly states that the tool has no side effects, nor does it mention auth needs, rate limits, failure behavior, or the response format, leaving notable gaps.

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 excessively long and mixes tool semantics with a full LLM workflow guide. It repeats similar instructions in the workflow, the 'IMPORTANT INSTRUCTIONS FOR LLM' section, and the 'KEY ANALYSIS POINTS' section, and the numbered list even has two separate '4.' items. It is front-loaded with purpose but far from concise.

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

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

There is no output schema, so the description should clarify what the tool returns, yet it only says 'current page structure' without describing the actual shape or fields. While the workflow context is extensive, the description does not fully prepare an agent to interpret the tool's response, especially since focusArea behavior and error cases are unaddressed.

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

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

The input schema already provides 100% parameter coverage with descriptions for both 'url' and 'focusArea', so the baseline is 3. The description only mentions calling the tool 'with the URL' and adds no extra meaning for either parameter; in particular, focusArea is never discussed in the description.

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

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

The description opens with a clear verb and object: 'Extract detailed page structure to prepare for mockup comparison and experience generation.' It also explicitly labels the tool as 'the FIRST STEP' in the mockup-to-experience workflow and distinguishes it from the deployment tool createActivityFromModifications, so an agent can tell what it is and is not for.

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 the tool: when a user provides a mockup/screenshot and wants to create an experience. It gives a concrete workflow sequence, including asking for a URL before invoking the tool and only calling createActivityFromModifications after user approval. It lacks explicit 'do not use when...' alternatives, which prevents a 5, but the context is strong.

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 must carry the behavioral burden. It implies a read-only operation from 'Get,' but it does not disclose response structure, error behavior, authentication needs, or whether any side effects occur.

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

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

The description is a single clear, front-loaded sentence with no filler. Every word contributes to conveying the tool's core purpose.

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 single-parameter getter, the description provides the essential purpose, and the schema covers the parameter. However, with no output schema and no usage context versus sibling list tools, it leaves minor but real gaps about what 'details' are returned and when to choose this 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 100%, with the 'id' parameter described as 'Offer ID.' The description adds little beyond the schema, but since the schema already fully documents the parameter, the baseline score of 3 applies.

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

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

The description says 'Get details of a specific offer,' which is a clear verb plus resource. It distinguishes from siblings like listOffers or createOffer by implying single-item retrieval by ID.

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 listOffers, createOffer, or updateOffer. The description only states what it does, not when it should be preferred over 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?

With no annotations, the description must carry the behavioral burden. It does this reasonably well by indicating a read-only audit retrieval, the default one-day window, and the optional timestamp filter. It does not disclose pagination or ordering, but these are not critical for this simple getter.

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

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

A single sentence that front-loads the core action and then efficiently adds the filtering dimensions and default behavior. There is no redundant wording or unnecessary background.

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 core purpose and parameters are covered well, and the schema fills in the remaining parameter details. However, there is no output schema and no distinction from getEntityRevisions, leaving the agent without information about return shape and sibling selection.

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?

All three parameters are fully documented in the input schema, so the schema already provides most of the semantics. The description adds only minor context about 'resource type' and 'author's name' filtering, which mostly restates the 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 clearly states the operation: getting all revisions/audit log entries for a resource type, filtered by author and optionally by timestamp. It is specific enough to understand the tool's main purpose, though it does not explicitly differentiate it from the similarly named sibling getEntityRevisions.

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 intended use is implied: call this when you need revision/audit history for a resource type, filtered by author and optionally by modified-after time. However, the description gives no explicit guidance about when not to use it or when to prefer the similar getEntityRevisions 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?

No annotations are provided, so the description carries the burden. 'Get' implies a non-mutating read operation, but the description does not disclose access requirements, refresh behavior, or potential side effects. It adds only return-content hints 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?

One sentence with the action and resource front-loaded, and no significant fluff. The minor redundancy between 'report data' and 'order information' is negligible.

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 report tool with no output schema, the description gives the essential purpose and a hint of return content, but it omits useful context such as the default behavior when reportInterval is omitted and how this report differs from sibling report 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 100%, so the baseline is 3. The description does not add parameter-level detail beyond the schema, though it does clarify that the report includes conversion metrics and order information.

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 ('Get') and resource ('orders report data for an Experience Targeting (XT) activity'), and specifies content ('conversion metrics and order information'), making its purpose clear and distinguishable from generic report or activity 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 identifies the target scenario (XT activity orders report), but does not explicitly state when to prefer it over sibling tools like getABOrdersReport or getXTPerformanceReport, nor 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?

No annotations are provided, so the description carries the behavioral disclosure burden. It does convey that this is a read-style report operation and lists the categories of data returned, which is useful. Still, it does not explain whether the report is computed live or cached, how the optional date range impacts the report, or what happens when no data exists.

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

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

One clean, front-loaded sentence with no filler. The verb, resource, activity type, and report contents are all present, and every word 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 simple two-parameter tool this is reasonably complete: it explains the purpose, resource, and high-level return contents. However, with no output schema and no annotations, the description could have added more precision about report fields or date-range behavior, which is a small but real gap.

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

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

Schema description coverage is 100%, so the schema already documents both parameters clearly. The description adds no additional parameter-specific meaning beyond what is already in the schema, so the baseline score of 3 is appropriate.

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

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

States the specific operation (get), the exact resource (performance report), and the target activity type (Experience Targeting/XT). The mention of metrics, conversions, and visitor data further distinguishes it from sibling report tools such as getABPerformanceReport, getAPTPerformanceReport, and getXTOrdersReport.

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 an Experience Targeting (XT) activity' provides a clear condition for when to use this tool, and sibling names make alternatives apparent. However, it does not explicitly call out when not to use it or name alternative tools, so it falls just 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?

With no annotations provided, the description carries the full burden. It correctly implies a read-only list operation and mentions optional filtering/sorting, but it leaves out behavioral details such as pagination defaults, whether archived/inactive activities are included, or how filtering is actually expressed given the schema only exposes limit, offset, and sortBy. This is a moderate transparency gap.

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

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

The description is a single, well-structured sentence with no redundant content. It front-loads the core purpose and immediately conveys the optional capabilities, making it easy for an agent to parse quickly.

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 operation with three optional and well-documented parameters, this description plus the schema is enough for correct invocation. It does not describe the return shape or pagination behavior, but no output schema exists and the operation is low-risk, so these omissions are not critical.

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

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

Schema description coverage is 100%: limit, offset, and sortBy each have clear descriptions. The tool description adds no parameter-level detail and only vaguely references 'filtering/sorting', which could even be slightly misleading since there are no explicit filter parameters. With full schema coverage, the baseline of 3 is appropriate.

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

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

The description uses the specific verb 'List' and resource 'Target activities', and notes optional filtering/sorting. This clearly distinguishes it from sibling tools like listProperties (different resource) and getABActivity (singular fetch). It is not a tautology and gives the agent an exact sense of 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 description states what the tool does but gives no guidance on when to choose it over alternatives. It does not mention getABActivity for retrieving a single activity or listProperties for properties, nor does it provide any when-not-to-use conditions. The only signal is the inherent 'list' framing, so usage context is effectively undirected.

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 states that returned objects contain 'id' and 'name' and implies a read-only list operation, but it does not explain pagination behavior, default limit/offset semantics, or any side effects. This is a meaningful gap for a tool that has limit/offset parameters yet says 'all audiences.'

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

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

The description is well-structured with USAGE and WORKFLOW sections, front-loading the purpose and then giving action-able steps. Some redundancy exists (step 1 restates the first sentence), but the overall organization is effective.

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?

Although there is no output schema, the description explains the key return fields (id, name) and provides a full integration workflow ending with createActivityFromModifications. It could be more complete by addressing pagination/defaults, but it covers the core usage scenario sufficiently.

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

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

Schema description coverage is 100%, so limit and offset are already documented. The description does not add default values or clarify how the parameters interact with 'all audiences,' providing only baseline value.

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

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

The opening sentence, 'List all audiences available in Adobe Target,' states a specific verb and resource. This clearly distinguishes it from sibling list tools like listProperties and listMboxes, and the follow-up workflow reinforces the resource and purpose.

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

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

The description explicitly states when to use it: 'when creating activities with audience targeting.' It does not mention exclusions or alternatives (e.g., when to use createAudience instead), but the intended 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, the description carries the full behavioral disclosure burden. 'List all mboxes' does communicate a read-only, unfiltered retrieval action, but it does not mention output shape, pagination, potential size, or any other operational behavior. Adequate but minimal.

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 focused sentence with no filler. It states the essential action and scope immediately and wastes no tokens.

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

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

For a zero-parameter, no-annotation list tool, the description is largely complete: it says what is listed and that it is all items. It could be slightly more complete by mentioning that there is no filtering or by noting the return behavior, but the simplicity of the tool lowers the burden.

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

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

The tool has zero parameters, so there are no parameter semantics to document. The schema coverage is 100%, and the description does not need to add parameter meaning beyond the empty schema.

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

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

The description states a clear verb ('List') and a specific resource ('all mboxes'), making the tool's purpose unambiguous. The word 'all' also distinguishes it from the sibling tool getMbox, which targets a single mbox.

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 tool should be used when an agent needs the full set of mboxes, but it provides no explicit guidance about alternatives such as getMbox for a single mbox or listMboxProfileAttributes for attributes. Usage is inferred rather than stated.

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

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

No annotations are provided, so the description carries the full burden. 'List all' conveys a read-only enumeration with no side effects, which is adequate for a zero-parameter tool. However, it adds no context such as pagination, ordering, or the meaning of 'associated with mboxes', leaving minor behavioral ambiguity.

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

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

A single, front-loaded sentence that states the verb and resource with no filler. Every word earns its place; nothing is redundant or missing in terms of brevity.

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

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

For a zero-parameter, read-only enumeration tool, the short description is nearly complete. The only gap is the absence of an output schema and any hint about the return shape, but for a list-all tool the expected return is inferable. Sibling names provide enough context to disambiguate.

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 is an empty object with zero parameters, so there is nothing for the description to explain. Per the rubric, zero-parameter tools receive a baseline of 4, and the description fully suffices since no parameter documentation is needed.

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

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

The description uses a specific verb+resource structure: 'List all profile attributes associated with mboxes in Adobe Target'. This clearly distinguishes it from siblings like listMboxes (lists mboxes themselves) and listProperties/listAudiences, so an agent can select it correctly without opening schemas.

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

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

No explicit when-to-use guidance, exclusions, or named alternatives are provided. The usage context is only implied by the resource being described ('profile attributes associated with mboxes'), which requires the agent to infer when this is the right tool versus listMboxes or listProperties.

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 present, so the description carries the full burden of behavioral disclosure. It communicates a read/list operation but does not mention pagination defaults, ordering, whether 'all' is actually bounded by limit/offset, or the response shape. This is minimal and leaves important behavior implicit.

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 with no filler, and the verb-resource pair is front-loaded. It is appropriately terse for a simple enumeration tool, though it sacrifices informative content for brevity.

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 tool with two optional parameters fully covered by the schema, this is minimally sufficient to make a basic call. However, with no output schema and no annotations, the agent must infer return format and pagination behavior, so the description is not fully complete on its own.

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?

Both parameters, limit and offset, are fully described in the input schema, giving 100% schema description coverage. The tool description adds no parameter-level detail beyond that, so it earns the baseline score for relying on 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 ('List') and resource ('offers'), so an agent can identify this as the enumeration endpoint for offers. It doesn't differentiate from sibling list tools like listProperties or listAudiences, and 'all' is slightly inconsistent with the pagination parameters, but the core purpose is unambiguous.

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

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

There is no guidance about when to use this tool versus alternatives such as getOffer, listProperties, or listAudiences. No exclusions, prerequisites, or recommended conditions are provided, leaving the agent to infer usage from the tool name alone.

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 present, so the description carries the full burden. 'List all properties' implies a read-only operation but does not disclose pagination, response format, authorization requirements, or whether there are any limits. Minimal behavioral context is provided.

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 short and front-loaded, but it is under-specified. Every word earns its place, yet the brevity comes at the cost of meaningful context, making it merely adequate rather than well-structured.

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

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

Given no output schema and no annotations, the description should provide more context about what properties are and what the response looks like. For a simple zero-parameter list tool it is minimally callable, but an agent would have no idea what to expect from the result or how it fits into the larger API.

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

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

The tool has zero parameters, so there is nothing for the description to explain. The baseline of 4 applies because schema coverage is effectively complete and no parameter semantics are needed.

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

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

The description states a clear action and resource ('List all properties'), so it is not a complete tautology. However, 'properties' is undefined and the description adds almost no detail beyond the tool name, making the purpose somewhat vague despite being grammatically clear.

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

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

There is no guidance about when to use this tool versus sibling list tools like listActivities, listOffers, or listMboxes. An agent is left to infer that 'properties' is a distinct resource, but no explicit context or exclusions 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 full burden. It does disclose the return contents (built-in and custom tokens with active status) and 'Retrieve' implies a read-only operation, but it omits details like whether only active tokens are returned, pagination, auth requirements, or error behavior.

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

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

A single front-loaded sentence with no filler: the verb and resource come first, followed by the inclusion criteria. Every word adds meaning.

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

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

For a zero-parameter list tool, the description conveys the core purpose and the contents of the result. However, with no output schema and no annotations, an agent is left without any expectation of the response shape, fields, or pagination behavior, so a bit more detail would make it fully self-sufficient.

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

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

The tool has zero parameters and the schema coverage is 100%, so there are no parameter semantics the description must clarify. Per the baseline for 0-param tools, this dimension is adequately served.

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 ('Retrieve list') and names the resource ('response tokens'), adding useful scope: built-in and custom tokens and their active status. It differentiates from sibling list tools like listProperties, listAudiences, and listOffers by naming the exact resource, though it doesn't explicitly contrast with the likely single-token sibling getResponseTokens.

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

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

No when-to-use guidance is provided. The description never mentions alternatives such as getResponseTokens for fetching a single token, nor any exclusions or conditions that would route an agent to this tool over the many siblings in the same family.

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, and it exceeds it. It discloses that this is a PUT request that replaces the existing definition, explains default value application, notes 15-minute API-to-UI latency, and warns that the activity state in the API may diverge from UI status. It also flags workspace privilege requirements for premium customers.

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 extremely well-structured with clear headers for defaults, use cases, states, behavioral notes, and a typical structure. Every section adds necessary information for correctly calling the tool, and the most critical facts (PUT semantics, defaults, state behavior) are front-loaded. Nothing feels redundant or irrelevant.

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?

This is a complex tool with nested objects and no output schema or annotations, yet the description covers defaults, required fields per state, state transitions, latency, permissions, and optional configuration fields. An agent has enough context to construct a valid request and anticipate system behavior. The only missing piece is return value details, but that is acceptable given the complexity and lack of 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?

Although the schema already describes both parameters at 100% coverage, the description adds substantial meaning: it clarifies that 'activity' contains a complete definition object, provides a typical update structure, lists optional fields, and explains required dates for approved state. This goes well beyond the schema's minimal 'Activity ID' and 'Complete updated activity definition object' 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 clearly states it updates an existing A/B Test activity definition, with a specific verb and resource, and lists concrete use cases. It explicitly distinguishes itself from updateActivityState, saying that tool is for state-only changes whereas this one is for full definition updates. This removes ambiguity about which sibling tool to use.

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

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

The description provides explicit when-to-use guidance via a USE CASES section and names the alternative tool for state-only changes. It also gives activity state definitions and state-with-dates behavior, so an agent knows exactly when to invoke this tool versus updateActivityState. This is strong, actionable 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 present, so the description carries the full burden of behavioral disclosure. It only states that the state is updated and lists the possible values; it does not explain whether transitions are restricted, whether the operation is reversible, what effects each state has on visibility, or what happens side-effect-wise.

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 sentence with no filler, and the primary action is front-loaded. It includes the essential state values without unnecessary elaboration, making it appropriately concise for the tool's simplicity.

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 mutation, the description is minimally adequate, but there are clear gaps. It omits usage guidance relative to the many sibling tools, transition constraints, side effects, and any indication of the response or error behavior, which matters more because no output schema or annotations are provided.

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

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

Schema description coverage is 100%, and both parameters already have meaningful descriptions: 'Activity ID' and the state enum with its values. The description adds no new parameter semantics beyond naming the state values, so the baseline of 3 applies.

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

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

The description clearly states the specific action: 'Update the state of an activity' and lists the three supported states, making the tool's purpose immediately understandable. It is distinguishable from the sibling updateABActivity by narrowing the scope to state changes, though it doesn't explicitly name or contrast the sibling.

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

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

No guidance is given about when to use this tool versus updateABActivity or other activity tools. There is also no mention of prerequisites, transition rules, or scenarios where this tool should or shouldn't be used, so the agent must infer usage from the name and schema alone.

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 discloses that this is a PUT request, that name is unconditionally required by the Adobe Target API, and shows how to preserve current content when updating only the name. Minor omissions such as response shape and permissions are secondary to the key API constraint.

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

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

The description is well structured: a one-sentence purpose, an IMPORTANT constraint, numbered workflow steps, and a concise tip. No sentences are filler, and the critical requirement 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 three-parameter update tool with no output schema or annotations, the description gives enough input semantics and workflow context for an agent to invoke it successfully. It could mention the consequence of omitting content on a name-only update more explicitly, but the workflow strongly implies current content must be supplied to preserve 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 coverage is 100%, so the baseline is 3. The description adds value by explaining how id, name, and content combine in three distinct update scenarios and by providing a fallback to getOffer for retrieving the current name.

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

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

The description opens with 'Update an existing offer' and details scope as 'name and/or content'. This is a specific verb+resource statement, and 'existing' distinguishes the tool from createOffer/listOffers siblings without ambiguity.

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

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

It provides clear context for when to use the tool and gives concrete workflow scenarios for content-only, name-only, and both. It names getOffer as a prerequisite lookup tool when the current name is unknown, though it does not explicitly contrast with createOffer when the offer is new.

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