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

Description discloses error behavior for free accounts and prerequisites (paid membership). No annotations are provided, so the description carries the full burden; it covers key behavioral aspects but could mention additional side effects or return 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?

Description is relatively concise but includes redundant details (supported sizes also in schema). However, the additional context about membership and detection adds value, so the verbosity is justified.

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

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

Given the schema fully covers parameters and no output schema exists, the description provides sufficient context for usage. It could mention what returns or side effects occur on success, but the core usage is 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 descriptions cover all parameters 100%, including URL requirements and supported sizes. The description adds context about membership and errors, though the parameter meanings are already well-defined 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?

Clearly states the action ('Creates a new banner ad'), specifies the resource (banner ad), and distinguishes from sibling tools by mentioning automatic location detection from image size, which is unique to this 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?

Provides explicit conditions: HTTPS requirement, supported dimensions, membership levels, and error conditions for free accounts. This gives clear guidance on when this tool should be used versus 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?

The description discloses key behaviors: it creates a link ad, returns the new ID, and errors for free accounts. It does not elaborate on other side effects, but for a create operation these are sufficient and no annotations are provided to cover them.

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

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

The description is concise, using three short sentences to cover purpose, flow, return value, and requirement. No unnecessary words or redundant details.

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

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

For a simple 2-parameter create operation without an output schema, the description covers the essential points: what it does, what it returns, and a key operating condition (paid membership). It omits no critical context for a typical use case.

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

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

The schema already provides descriptions for both parameters (url and title) with full coverage. The tool description adds context about the overall flow but does not further clarify parameter meaning beyond the schema, so it stays at the baseline for full 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 explicitly states the tool's purpose: 'Creates a new link ad.' It also clarifies the flow, return value, and membership requirement, making it distinct from sibling tools that create other ad types (e.g., create_banner, create_youtube_ad).

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 indicates when to use the tool (to create a link ad) and includes an important usage condition (requires paid membership, error otherwise). It does not explicitly contrast with sibling tools, but the ad-type distinction is clear from the tool 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 disclosing behavior. It mentions that free accounts receive an error, which is a clear behavioral note. However, it does not describe success behavior (e.g., what is returned) or any side effects, leaving some behavioral aspects unspecified.

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 that puts the primary action first ('Creates a new press release / blog article') and then adds the essential membership constraint. It is concise with no extraneous information, making it easy to parse and act upon.

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 schema is simple (flat, no enums, no nested objects) and the description covers the core purpose and a key constraint. However, it lacks any mention of return values or the distinction between creating a draft and publishing (sibling tools include post_press_release). This omission leaves some contextual ambiguity for an agent deciding which tool to use.

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 descriptions for all parameters (100% coverage), so the description adds no additional meaning to the parameters. The tool description does not clarify parameter usage beyond what the schema already states, keeping it at the baseline for high 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 clearly states the tool's function: 'Creates a new press release / blog article.' It explicitly names the resource (press release) and the action (create), and the mention of 'blog article' broadens its scope. This effectively distinguishes it from sibling tools like create_banner or create_youtube_ad.

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

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

The description provides a business constraint ('Requires a paid membership') and notes an error condition for free accounts, but it does not offer comparative guidance on when to use this tool versus alternatives such as update_press_release or post_press_release. There is no explicit instruction about selecting this tool over others for creating versus updating or publishing.

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

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

The description discloses side effects (emails followers once per video) and access requirements (paid membership), and explains the distinction between active and disabled status. It does not cover reversibility or deletion, but the main behavioral aspects are transparent.

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

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

The description is concise and to the point, containing only essential information without redundancy or unnecessary elaboration. It is well-structured with clear sentences covering purpose, status behavior, and requirements.

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 provides sufficient context for the tool's operation, including membership requirements and error conditions, but does not specify the success response or return structure. Given the absence of an output schema, this minor omission is acceptable but not fully complete.

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

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

All four parameters (title, status, description, youtube_link) are described in the schema, with additional detail in the description for status (active/disabled) and youtube_link (accepted formats). The description fully clarifies the meaning and allowed values for each parameter.

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

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

The description clearly states that the tool creates a YouTube video ad, explains the automatic video ID derivation from the link, and specifies the effects of the status parameter. It is unambiguous about the tool's primary action.

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

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

The description mentions a prerequisite (paid membership) and failure condition (error for free accounts), but does not explicitly indicate when to use this tool versus other link or ad creation tools. It lacks guidance on typical use cases or scenarios.

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. It states what is returned and that no paid membership is required, but does not explicitly confirm it is read-only or mention any side effects, rate limits, or error behavior. It is not misleading but incomplete.

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

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

The description is two sentences, directly states the returned data and the target user, with no extraneous information.

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

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

Given there is no output schema, the description adequately lists the specific data returned (credits, post slots, links viewed, links remaining) and the scope (authenticated user), which is sufficient for a simple getter.

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

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

There are no parameters, so there is nothing to describe. The description is consistent with the empty schema and no additional parameter guidance 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 clearly states the tool returns a set of credit-related metrics (credits, post slots, links viewed, links remaining) for the authenticated user, with no ambiguity about its function.

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

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

The description implies when to use it (checking account credits) and explicitly notes it works for free accounts, but does not explicitly contrast with alternatives. Given the sibling tools are all about content operations, the purpose is clear enough.

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

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

With no annotations, the description carries the full burden. It discloses the paid-membership requirement, error for free accounts, and one-hour cache behavior. It does not explicitly state it has no side effects, but the read-only return nature is clear.

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

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

The description is dense but each clause adds necessary information: metrics covered, aggregate-only scope, caching, and access requirements. 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?

Given no output schema, the description enumerates all returned data categories and key behavioral constraints. An agent has enough context to understand the tool's capabilities and limitations.

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 no parameters and the schema confirms an empty object. There is nothing for the description to add beyond the schema, so this dimension is fully satisfied.

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

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

Clearly states it returns trailing-30-day platform performance aggregates, enumerating the exact metrics and categories. This distinguishes it from sibling tools that list individual entities or manage content.

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

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

Implicitly indicates use when aggregate platform-wide performance data is needed and explicitly notes it provides aggregates only, not per-member data. Does not name sibling alternatives or state 'use when X', but the scope is well conveyed.

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

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

The description discloses that it requires authentication ('for the authenticated user') and that it is available to free accounts, which are useful behavioral notes. However, it does not explicitly state that it is a read-only operation, nor does it mention any side effects, rate limits, or other behaviors. Given no annotations are present, the description carries the burden but only partially covers transparency.

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

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

The description is two sentences, concise and front-loaded. It first states the core functionality (returns referral counts) and then adds a relevant note about free account availability. No unnecessary words or details are included.

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

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

The tool is simple, and the description specifies the time periods and the user scope. It does not detail the exact output structure (e.g., whether counts are in a list or object), but since no output schema is provided, the description offers sufficient context for an agent to understand the tool's purpose and expected return. It is slightly incomplete in not specifying the return format explicitly, but not critically so.

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 input schema is empty, so the schema coverage is trivially 100%. The description adds no parameter-related information because there are none to describe. Per the rubric, with high schema coverage, a baseline of 3 is appropriate, and the description does not add extra meaning beyond the schema.

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

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

The description clearly states the tool returns referral counts for specific time periods (today, last 7 days, last 30 days, all time) for the authenticated user. It uses a specific verb and resource, and the scope is unambiguous, distinguishing it from sibling tools that handle links, banners, or other data.

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

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

The description implies usage by describing the returned data, but it does not explicitly state when to use this tool versus alternatives. There is no mention of when not to use it or how it compares to other tools, leaving the context implicit rather than explicit.

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

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

No annotations are provided, but the description implies a read-only, safe operation. It does not explicitly state side effects, but the nature of a health check is understood to be non-destructive.

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—two sentences—and front-loads the core purpose (connectivity check) before providing supplementary details about the return values and access requirements.

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 absence of parameters and a simple output, the description fully covers what an agent needs to know to invoke the tool correctly. It includes the return payload and access condition, making 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?

The tool has no parameters, so schema coverage is complete. The description adds meaningful detail about what the tool returns (username, membership status) 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 clearly states the tool checks API connectivity and returns the authenticated user's username and membership status. It uses a specific verb and resource, and differentiates from sibling tools that perform CRUD or listing operations.

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

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

It explicitly notes that no paid membership is required, clarifying accessibility. While it doesn't contrast with alternatives, the purpose is self-explanatory and no other sibling tool serves this health-check function.

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

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

With no annotations provided, the description must carry the full behavioral burden. It states the operation (returns active banners owned by the user) and the access requirement (free accounts), but doesn't mention response format, pagination, error behavior, or side effects. For a read-only list tool, this is adequate but not exhaustive.

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

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

Two concise sentences that front-load the core purpose ('Returns all active banner ads owned by the authenticated user') and then add the key access condition. Every word earns its place; there is no fluff or redundancy.

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

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

Given the lack of parameters and output schema, the description is largely complete for a list operation. It specifies the resource scope, ownership, and access level. Minor omissions like pagination or ordering are not critical for such a simple tool, so a 4 is appropriate rather than a 5.

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

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

The tool has zero parameters, so the description doesn't need to explain parameter meaning. The schema is empty and coverage is 100%, leaving nothing for the description to add. The baseline for no-parameter tools is 4, and the description meets that without unnecessary parameter-related content.

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 ('Returns') and resource ('all active banner ads') with clear ownership ('owned by the authenticated user'). It distinguishes itself from sibling list tools (list_links, list_youtube_ads, etc.) by specifying the resource type and 'active' status.

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

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

It provides clear context (for banner ads) and an important access guideline ('Does not require a paid membership; available to free accounts too'), which tells agents when this tool is usable. It doesn't explicitly name alternatives or say when not to use it, but the resource-type specificity makes the intended use obvious.

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 transparently indicates a read-only listing operation and its filter criteria, though it does not mention pagination or rate limits.

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

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

Two sentences convey the essential purpose and accessibility without any redundant words.

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

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

For a zero-parameter, no-output-schema tool, the description sufficiently explains the returned data and the user scope, leaving no critical 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?

The tool takes no parameters, so the description fully covers what an agent needs to know; schema coverage is complete.

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

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

Clearly states the tool returns active, non-reported link ads owned by the authenticated user, distinguishing it from sibling list tools for other ad types.

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

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

Provides context that it works for free accounts, aiding selection, though it does not explicitly contrast with sibling list tools.

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

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

With no annotations, the description carries the full burden, and it does disclose free-account availability and that the operation returns rows. However, it does not explicitly state that the operation is read-only, nor mention side effects, pagination, or error behavior, leaving some 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?

The description is compact and front-loads the key purpose in the first sentence. The field lists are somewhat long but directly support the purpose by showing what varies by ad type, so they earn their place.

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

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

There is no output schema, so the description's enumeration of the per-type fields is helpful. Yet it stops short of giving a complete result shape, including field types, ordering, or pagination, so an agent still has to infer some details about the response.

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

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

Schema covers both parameters with descriptions and enums, so the baseline is 3. The description adds context about output fields per type but does not add additional meaning to the 'type' or 'status' parameters beyond what the schema already provides.

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

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

Description uses the specific verb 'Returns' and identifies the resource as 'ad placement (post)', then enumerates the performance fields for each ad type. This clearly distinguishes list_posts from the sibling type-specific tools like list_links and list_banners by presenting it as the cross-type listing operation.

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

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

The description implies that this tool is the general list for all ad placement types by enumerating banner, link, YouTube, and press-release fields, but it never explicitly says to prefer this over sibling tools or when to use a type-specific list. Usage guidance is therefore only implicit.

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

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

No annotations are provided, so the description carries the full burden. It clearly indicates a read-only operation ('Returns') and defines the scope ('owned by the authenticated user'), while also disclosing access limitations. No side effects are implied or hidden.

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

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

Two concise sentences: the first states the primary function with precision, the second addresses access. No redundant or extraneous words.

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

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

Given there are no parameters and no output schema, the description fully covers what the tool does (returns press releases), the filtering criteria (active, non-reported), ownership (authenticated user), and access requirements. Nothing essential is missing.

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

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

With 0 parameters, the schema coverage is complete, and the baseline is 4. There are no parameter details to add, so the description appropriately adds no parameter 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?

Clearly states the verb 'Returns' and the resource 'press releases / blog articles', with scope 'all active, non-reported' and ownership 'authenticated user'. This distinctly differentiates it from sibling list tools like list_links or list_banners.

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 specifies what is returned (active, non-reported press releases) and clarifies access requirements ('Does not require a paid membership'). While it doesn't name alternatives, the resource-type specificity makes the appropriate use case unambiguous.

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

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

With no annotations, the description carries the full burden of behavioral transparency. It discloses that the tool filters for active and non-reported ads, requires authentication, and is available on free accounts. While it does not explicitly state that it is read-only or mention pagination, the 'Returns' verb implies a read operation, and the provided details offer reasonable transparency.

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

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

The description is highly concise, consisting of exactly two sentences. The first sentence presents the core functionality and filters, while the second adds a relevant access note. No unnecessary words or redundancy are present.

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

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

For a simple list operation with no parameters and no output schema, the description provides sufficient context. It clarifies the ad type, the filters (active, non-reported), and the ownership scope. While it does not describe the response format, that information is not critical for understanding the tool's basic purpose.

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

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

The tool has no parameters, so the baseline score is 4. The description does not need to explain any parameters and does not attempt to, which is appropriate given 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 explicitly states that this tool returns YouTube video ads, specifying both the resource type and the scope (owned by the authenticated user). It also includes filtering criteria (active, non-reported) which further clarifies its purpose and distinguishes it from sibling tools that handle other ad types.

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 mentions that it lists YouTube video ads and notes that free accounts can use it, which provides some usage context. It does not explicitly contrast with alternatives like list_banners, but the resource type is unambiguous enough that an agent would know when to select this tool over others.

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 explains the credits cost, membership requirement, and error condition for free accounts. However, it does not detail side effects such as whether the banner becomes publicly visible immediately or if the action is reversible, leaving slight 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?

The description is concise and clear, with two sentences that front-load the primary action and then provide essential constraints. Every sentence adds necessary information without 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?

Given the tool's simplicity, the description covers the essential context: prerequisites (paid membership, credits), the action, and the error condition for ineligible users. It does not include an output schema, but that is not required for the tool's purpose. Minor missing details like confirmation of success are acceptable for this scope.

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

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

The schema already describes both parameters, but the description adds valuable context: days are limited to 1-2 for paid members and credits are charged per day. This enriches the meaning of the parameters, though it does not cover every possible edge case (e.g., behavior when days exceed the limit).

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

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

The description clearly states the tool's action (posts an existing banner into rotation), the resource involved (banner), and the additional context of credits and membership. It implicitly distinguishes from sibling tools like create_banner by focusing on posting an existing banner.

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 specifies when the tool should be used (paid members with credits) and provides a clear condition for non-use (free accounts will get an error). It also mentions the required membership tiers, giving concrete guidance.

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

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

With no annotations, the description covers key side effects: credit usage, derived view_time/view_credits, pending vs active status, and the paid-membership requirement. It does not mention failure modes like insufficient credits, but the core behavior is transparent.

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

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

The description is duplicated verbatim, doubling the length without adding any new information. This severely violates the conciseness principle, as every sentence should earn 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?

The description covers return fields, membership requirements, approval flow, and credit derivation, providing enough context for an agent to call the tool correctly. It lacks explicit error handling details but is otherwise 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?

All five parameters have schema descriptions, and the description adds meaningful business context: ad_days is constrained to 0, icon/bold/double_time affect credits, and double_time is exemplified with a concrete credit cost.

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

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

The description clearly states the tool posts an existing link ad into rotation using credits and mirrors the web free-post flow. It distinguishes this from create_link and other post_* siblings by emphasizing existing links and credit-based placement.

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 explicit constraints: ad_days must be 0, sponsored placements are not available, and a paid membership is required. It also explains approval behavior, though it does not explicitly compare with post_banner or post_press_release.

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 indicates a mutation ('posts') and mentions that it returns an error for free accounts, making the side effects and failure conditions transparent. It does not claim to be read-only or hide the write nature of the operation.

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

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

The description is two sentences, directly communicates the core action and constraints, and contains no unnecessary words or repetition. It is well-structured and efficient.

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

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

It provides sufficient context for an agent to decide when to call the tool, including the membership requirement, the error condition for free accounts, and the cost in credits. It also clarifies the action and target, making it complete for the given scope.

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

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

The schema already provides descriptions for both parameters (press_release_id and days) with 100% coverage, so the description text adds limited new meaning about the parameters themselves. It does provide context about credits and duration, but this is more about usage than parameter semantics. 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 that the tool posts an existing press release to the home-page widget, specifies the required credits and duration, and mentions the membership requirement. The action, object, and destination are unambiguous.

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

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

It explicitly states that a paid membership (Bronze/Silver/Gold) is required and that free accounts will receive an error, providing clear guidance on when to use and when not to use the tool. It also mentions the credit cost and duration, which inform usage decisions.

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 transparently conveys behavioral details: partial updates, the email side effect, membership requirement, and error for free accounts. This is more than adequate.

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

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

The description is concise and well-structured, using two sentences to cover core behavior, side effects, and constraints without unnecessary fluff.

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

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

Given the absence of annotations and output schema, the description sufficiently covers what the tool does, key side effects, and failure conditions. No critical information is missing.

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

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

The schema provides descriptions for all parameters, and the description adds key context about partial updates and the status side effect. This enhances understanding beyond the schema alone.

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

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

The description clearly states the tool's purpose: partially updating an existing press release. It distinguishes from creation and posting by emphasizing 'only supplied fields change' and the ownership requirement.

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 implies when to use it (when updating existing press releases) and notes important side effects (status 1 emails followers) and prerequisites (paid membership). However, it doesn't explicitly contrast with sibling tools like post_press_release, but the phrasing is sufficient for most cases.

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 transparency burden. It discloses the important side effect of emailing followers when status is set to 1, the membership prerequisite, and the error for free accounts. It could be more detailed about return values or other edge cases, but the key behavioral impacts are covered.

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

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

The description is concise and well-structured, with the core behavior stated first and important caveats following. Every sentence adds value, 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?

Given the moderate complexity and absence of an output schema, the description is sufficiently complete. It covers the operational context, ownership requirement, partial-update semantics, the email side effect, and membership prerequisite. No critical missing information prevents correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful context beyond the schema: youtube_ad_id must belong to the user, status 1 emails followers, and youtube_link is re-derived into a video ID. This extra detail helps the agent understand implications that raw schema constraints do not convey.

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

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

The description clearly states the tool partially updates an existing YouTube ad owned by the user, with only supplied fields changing. It uses a specific verb ('updates'), identifies the resource ('YouTube ad'), and distinguishes it from creation by emphasizing 'existing' and 'partial update'.

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

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

The description provides clear usage guidance: it updates existing ads, only supplied fields change, and it warns that setting status to 1 emails followers once ever. It also notes the paid membership requirement and that free accounts receive an error. It does not explicitly name alternative tools like create_youtube_ad, but the 'existing' and 'partial update' language makes the intent clear.

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

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

No annotations are provided, so the description carries the burden. It states the action and the membership requirement, but it does not disclose whether the upload is a write operation that persists data, whether it is idempotent, or any side effects beyond returning a URL. Some behavioral details are missing.

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

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

The description is compact—two sentences—and includes all essential details without redundancy. It is well-structured with clear conditions and constraints, making it efficient to parse.

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 4 parameters and no output schema, the description covers the core usage, input options, and constraints. It does not mention error scenarios or URL permanence, but these are not critical for selecting and invoking the tool. Overall, it is complete enough for an agent to use correctly.

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

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

The schema already describes each parameter, but the description adds critical context: max file size, allowed formats, that base64 requires a filename, that file_path overrides base64, and the exact banner dimensions. This significantly enriches the parameter meanings beyond the schema.

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

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

The description clearly states the action (upload image), the resource (image), and the purpose (to get a hosted HTTPS URL for banner or article usage). It also specifies supported formats and size limit, leaving no ambiguity about the tool's function.

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

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

It explicitly instructs to provide either a local file path or base64 content with a filename, and clarifies that banner type requires matching dimensions. The paid membership requirement is also disclosed, giving the agent clear conditions for successful use.

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