reddit-ads-mcp

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

Annotations already declare readOnly=false, destructive=true, openWorld=true, so the safety profile is covered. The description adds real context beyond that: the base URL the path is relative to and the non-obvious {"data": {...}} body-wrapping convention for POST/PATCH/PUT. It omits auth/permission requirements and rate-limit behavior, which would be valuable for a destructive open-world tool.

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

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

Three tight sentences, each earning its place: what it does, when to use it, and the two non-obvious formatting conventions. The purpose and gating condition are front-loaded.

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

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

For a raw proxy with no output schema, the description covers the essentials an agent needs: base URL, path form, and body envelope. It leaves out auth prerequisites, response/error shape, and any hint about which endpoints exist, which matters given the tool's open-world, destructive nature.

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 75% and the schema already describes path, body, and query. The description adds information the schema lacks: the base URL that 'path' is relative to and the body-wrapping convention, which materially change how an agent constructs the call. It does not clarify the query parameter value types or method semantics further.

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

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

States a specific verb+resource: 'Call any Reddit Ads API v3 endpoint directly.' In a family of ~100 dedicated endpoint tools, it clearly marks itself as the raw escape hatch, so an agent can distinguish it from every sibling without opening a schema.

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

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

'Use for endpoints without a dedicated tool' gives an explicit selection condition that routes the agent correctly relative to the dedicated tools. It does not, however, name specific alternatives or warn against using it when a dedicated tool exists for a mutation, so the routing is clear but not maximally explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read profile is covered. The description adds nothing about what a failure looks like, whether it makes a network round-trip, or any rate-limit behavior, so it is only mildly additive.

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

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

A single front-loaded sentence with no filler. Every word 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 trivial no-param, no-output-schema tool, the description does convey the essential return semantics (credential validity). It could still say what to do on failure, but the core need is met.

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, which per the baseline yields a 4. There is nothing in the schema for the description to clarify, and it correctly implies no input is required.

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

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

States a specific verb and resource ('show whether the server holds valid Reddit Ads credentials'), which is immediately distinguishable from the login/logout siblings. It is clear but never names those alternatives, so it stops short of a 5.

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

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

No when-to-use guidance is given. The description does not say to run this before other Reddit Ads calls, nor how it relates to reddit_ads_login or reddit_ads_logout, leaving the agent to infer the workflow.

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

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds real value beyond them: the default PAUSED status and the dependency on a pre-existing post. It does not mention authorization requirements or what the response returns, but for a create tool with no output schema that is a minor gap.

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

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

Three short sentences, front-loaded with the action, then prerequisite, then default status. Every sentence carries actionable information; nothing is redundant with the schema.

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

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

For a create-only tool with no output schema, the description covers the prerequisite, the id format, and the default status. It does not note the required ad_group_id/name/configured_status explicitly, though those are already in the schema.

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

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

Schema coverage is 100% and the nested data object is thoroughly documented, so baseline is 3. The description still adds the t3_... post_id format and where that id comes from, tying the parameter to the prerequisite tool rather than leaving it as a bare string.

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

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

States a precise verb+resource+scope: 'Create an ad in an ad group.' This clearly separates it from reddit_ads_create_campaign and reddit_ads_create_ad_group, and it further distinguishes the standard-ad path from the Reddit Max flow.

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

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

Gives the explicit prerequisite chain — create the post first with reddit_ads_create_post_job (or reddit_ads_create_post) and pass its post_id — and states the default operational behavior ('Create it PAUSED unless the user asks otherwise'). The agent knows both how to prepare and how to invoke.

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

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

Annotations already declare a non-read-only, non-destructive, open-world write. The description adds genuinely new behavioral facts beyond that: the default PAUSED status, the micro-currency convention (1 USD = 1000000), and the CBO constraint that several fields must match the campaign with goal_value null. It does not mention permissions or response behavior, but the added context is substantive.

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

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

Four front-loaded sentences, each carrying a distinct constraint (hierarchy, currency, default state, CBO rule) with no filler. Slightly dense but every sentence earns its place.

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

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

Given a deep nested schema, no output schema, and full schema coverage, the description supplies the defaults and cross-field constraints the schema cannot express. It is nearly complete for correct invocation; only permission/auth context is absent, which is minor here.

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

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

Schema description coverage is 100%, so a baseline of 3 would apply. The description goes further, clarifying the micro-currency unit for monetary fields and the CBO rule that bid_strategy, bid_type, goal_type, optimization_goal and view_through_conversion_type must match the campaign and goal_value must be null — semantics not present 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?

States a specific verb and resource ('Create an ad group') and situates it in the object hierarchy ('inside a campaign'), which orients the agent relative to reddit_ads_create_campaign and reddit_ads_create_ad. It does not explicitly name those siblings, so it falls just short of full sibling differentiation.

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

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

Gives clear operational guidance ('Create it PAUSED unless the user asks otherwise') and a conditional prerequisite for campaign budget optimization. It does not cover when to prefer this tool over alternatives or ordering requirements relative to campaign creation, but the context is well supplied.

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

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

Annotations already declare this is a mutating (readOnlyHint=false), non-destructive, open-world operation. The description adds two behaviorally important details not present in the structured data: the micro-currency money convention and the PAUSED-by-default creation behavior. It does not describe the response or post-creation side effects, keeping it short of a 5.

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

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

Three short sentences, the action front-loaded first, followed by the two constraints that most affect correct invocation (units and default status). No filler or redundancy.

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

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

For a creation tool with rich nested schema documentation and annotations covering the safety profile, the description covers the highest-risk gotchas (currency units, default paused state). Without an output schema, one might want a note on the returned campaign ID, but the essentials are present.

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 nested data object is documented exhaustively (objectives, bid strategies, scheduling, etc.), so the schema carries parameter semantics. The description only adds the micro-currency unit convention, which is relevant for money fields but otherwise marginal beyond the schema baseline.

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

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

States a specific verb (Create) and resource (campaign) in the title and first sentence, so the action is unambiguous. However it does not differentiate this tool from close siblings such as reddit_ads_create_ad_group or reddit_ads_create_ad, relying on the agent to infer the hierarchy.

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 instruction 'Create it PAUSED unless the user asks otherwise' gives a concrete default behavior, which is useful. But there is no guidance on when to use this versus update_campaign or create_ad_group, and no prerequisites are stated, so usage is only implied.

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

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

Annotations already declare this is a non-read, non-destructive, open-world write (readOnlyHint=false, destructiveHint=false, openWorldHint=true), which covers the safety profile. The description adds nothing beyond that—no mention of auth/permission needs, whether catalogs are unique per business, or what side effects creation triggers.

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 zero filler is efficient. It is arguably under-specified rather than verbose, but as written nothing wastes space.

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 create mutation with an open-world hint, no output schema, and a nested required data object, the description omits return information, required-field expectations, and any ordering/prerequisite context. An agent would need to open the schema and guess at the rest, so it is incomplete for the tool's 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 coverage is 50%: the nested data object documents name, default_language, default_currency, and event_sources, but business_id carries no description. The prose adds no parameter meaning of its own, so it neither compensates for the gap nor detracts. Baseline 3 given the mixed 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 states a clear verb+resource ("Create a product catalog") and adds the purpose ("for dynamic product ads"), so an agent knows this is the creation counterpart to list/get/update/delete_catalog. It does not explicitly name or contrast those siblings, but the operation 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 when-to-use guidance, no prerequisites (e.g., a business must exist first), and no mention of alternatives such as reddit_ads_update_catalog or the product-feed tools. The agent is left to infer usage entirely from the tool name.

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

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

Annotations already declare this is a non-read-only, non-destructive, open-world mutation, so safety is covered. The description adds the post-creation user-population step, which is real behavioral context, but says nothing about permissions, idempotency, or whether a duplicate-named audience is created.

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

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

Two short sentences, front-loaded with the core action and followed by the single most useful next-step pointer. No filler or redundancy.

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

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

With annotations covering the safety profile, a fully documented schema, and no output schema, the description covers creation plus the key follow-up step. Minor gap: it never acknowledges the three distinct audience types at a high level, leaving the reader to discover them in the schema.

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

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

Schema description coverage is 100% and the nested 'data' description exhaustively documents the three audience types and their config fields, so the schema does the heavy lifting. The description adds no parameter meaning beyond that, which is the expected baseline at full 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?

States a specific verb and resource ('Create a custom audience'), which distinguishes it from siblings like create_saved_audience and create_catalog. However it does not explicitly contrast with those siblings, so the reader must rely on the name alone to disambiguate.

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 one concrete workflow hint: for customer lists, add users afterwards via reddit_ads_update_custom_audience_users. That is genuinely useful, but there is no guidance on when to prefer a custom audience over a saved audience, nor on prerequisites or account scoping.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the write-vs-read profile is covered. The description adds genuinely useful behavioral context by naming the required OAuth scope, which is not in the annotations or schema. However, it omits the most important behavior of a job-creating tool: that it is asynchronous, returns a job handle, and that the deletion is not immediate — relevant given the tension between the word "deletion" and destructiveHint=false.

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 scope requirement is placed inline where it is read. It is arguably too terse for a mutation tool, but on this dimension the economy is a strength rather than padding.

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

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

For a write tool with a nested-object schema, no output schema, and 50% schema coverage, the description leaves the agent without essential context: whether the operation is async, how to verify completion, whether the request is idempotent, or what identifiers are accepted. Annotations carry only the basic safety profile, so the description's burden was higher than it delivers.

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 only 50%: the leaf "value" field and "ad_account_id" are documented, but the required "data"/"identifiers" wrapper and the 200-identifier cap are covered only by structural constraints. The description adds no parameter information at all — it never mentions identifiers, the five supported identifier types, hashing requirements, or the batch limit — so it fails to compensate for the coverage gap.

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+resource pair ("Request deletion of a person's data from an ad account"), which is more precise than the title's generic "Delete user data". It implicitly separates itself from the sibling reddit_ads_create_pixel_data_deletion_job by scoping to an ad account, but never names or contrasts that sibling explicitly.

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

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

The only usage-relevant guidance is the parenthetical scope requirement ("requires the adsdatadeletion scope"). There is no statement of when to use this tool versus the pixel data-deletion sibling, no mention of prerequisites (e.g., the ad account must exist), and no hint that a companion tool like get_data_deletion_job exists to check the outcome.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the basic safety profile is covered. However, the description adds nothing beyond that: it does not mention required fields, that the form is created in an ad account, any auth requirements, or what the resulting form object looks like. With annotations present the bar is lower, but a mutation tool that adds zero behavioral context lands at a 2.

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?

It is a single short sentence with zero waste, but it is under-specified rather than concise. The one sentence conveys nothing the tool name did not already convey, so brevity here is a deficiency, not a virtue.

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 creation tool with a nested required object (questions with at least one entry) and no output schema, yet the description explains none of the mandatory shape, the account scoping, or the result. The schema rescues callability, but the prose leaves the agent without any operational context.

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

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

Schema description coverage is 100% – the nested data object already documents name, privacy_link, prompt, and the questions array with its enum types and constraint. The description adds no parameter meaning on top of that, 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?

"Create a lead generation form" simply restates the tool name and title with no additional specificity. It does not distinguish this tool from its siblings reddit_ads_get_lead_gen_form or reddit_ads_list_lead_gen_forms beyond the obvious verb, nor does it hint at what a lead gen form requires.

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, what prerequisites exist (e.g., an ad account or business context), or how it relates to the sibling list/get form tools. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is partly covered. The description adds genuinely useful context by disclosing the required scope and the business-admin role needed to invoke it. It stops short of describing the async job behavior or return/status handling.

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 naming the action, resource, and the gating requirement in a parenthetical. No wasted words.

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

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

For an open-world, mutating job-creation tool with nested parameters and no output schema, the description gives prerequisites but no sense of rate limits, job lifecycle, or how the resulting job is retrieved. Adequate but leaves meaningful gaps for a compliance-sensitive data deletion operation.

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

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

Schema description coverage is 0%, so the description must carry the load; it conceptually maps 'person's data' to the data/identifiers payload and 'a pixel' to pixel_id. However it omits the meaningful constraints in the schema (identifier type enum, SHA-256 hashing option, maxItems of 200), so it only partially compensates.

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

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

States a specific verb and resource: requesting deletion of a person's data collected by a pixel. This distinguishes it from the sibling reddit_ads_create_data_deletion_job by scoping to pixel-collected data, though the sibling relationship is left implicit rather than 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?

The prerequisite (adsdatadeletion scope and business admin) is a useful precondition, but there is no guidance on when to choose this tool over the generic reddit_ads_create_data_deletion_job sibling or the get_data_deletion_job follow-up. Usage is only implied by the pixel-specific framing.

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

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

Annotations already declare readOnly=false, destructive=false, openWorld=true, so the safety profile is covered. The description adds that execution is synchronous and that it is the legacy API, which is genuinely useful behavioral context versus the async job path, but nothing about auth needs, rate limits, or side effects.

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

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

Two short sentences, front-loaded with the action and scope, followed immediately by the preferred alternative. Zero 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 2-param mutation with a complex nested payload and no output schema, the description covers purpose and the preferred alternative but says nothing about the return value of the synchronous call or the meaning of profile_id. Adequate given the rich data schema and annotations, but with gaps.

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

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

Schema coverage is 50%: the nested data field is richly documented (types, content array, call_to_action enum values), but profile_id carries no description and the tool description adds no parameter detail of its own. Given the thorough schema for data, baseline 3 is appropriate, though it does not compensate for the undocumented profile_id.

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

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

States a specific verb (Create) and resource (a post on a profile), and explicitly flags it as the legacy sync API. It names the sibling it relates to (reddit_ads_create_post_job), so an agent can distinguish it from the job-based path without opening a schema.

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

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

"Prefer reddit_ads_create_post_job" gives explicit routing to the alternative and a clear preference signal. It does not fully spell out the narrow cases where the legacy sync path is still appropriate, but the primary when-to-use guidance is present.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, marking this as a write operation. The description adds the crucial async behavior (results must be polled rather than returned inline) and the input constraint (public video URL), which annotations do not convey. It omits auth/permission requirements and any rate-limit context.

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

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

Two tight sentences, front-loaded with purpose and followed by the required follow-up action. Every clause earns its place with no redundancy.

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

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

For a single-parameter async job creator with no output schema, the description covers the essentials: what it makes, from what input, and how to retrieve results. Explicit mention of the returned job identifier or how to match it to a poll call would complete it.

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

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

Schema description coverage is 0%, so the description must carry the burden. It adds real meaning by specifying the URL must point to a public video, but it does not explain the nested 'data' wrapper or format expectations beyond the schema's uri type.

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

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

States a specific verb ('Generate'), a clear resource ('poster (thumbnail) images'), and the input scope ('from a public video URL'). It also names the sibling get_poster_job, letting an agent distinguish the creator from the poller without opening either schema.

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

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

Explicitly tells the agent the follow-up workflow: poll reddit_ads_get_poster_job for the result, which is the key usage instruction for an async job. It lacks explicit when-not-to-use guidance versus alternatives like upload_creative_assets, so it falls short of a 5.

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

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

Annotations already declare it is a mutation (readOnlyHint=false) and open-world. The description adds substantial context beyond them: the operation is asynchronous, results are retrieved via polling, and media is fetched by Reddit from public URLs. Failure semantics and any rate limits remain undisclosed.

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

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

Three tight sentences, front-loaded with the action and async nature, then the follow-up path. No filler; every sentence carries actionable 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?

With no output schema, the description correctly explains how the return value is obtained (poll for the post_id) and covers the media-sourcing behavior. For an async mutation tool this is nearly complete, though it omits error handling and whether fields like allow_comments have defaults.

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 50%; the 'data' object is exhaustively documented in the schema itself (creative types, call_to_action enums, required fields), while profile_id carries no description. 'On a profile' lightly explains profile_id but the description contributes essentially no parameter detail beyond what the schema provides.

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

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

The description states a specific verb and resource ('Create an ad post on a profile') and adds scope via 'structured' and 'asynchronously'. It hints at the workflow, but does not explicitly differentiate from close siblings like reddit_ads_create_post or reddit_ads_create_poster_job, leaving the agent to infer the distinction.

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?

Clear downstream workflow is given: poll reddit_ads_get_post_job until SUCCESS, then use the post_id with reddit_ads_create_ad. That routes the agent across the async boundary well. It stops short of stating when to choose this tool over the non-job create 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?

Annotations already indicate this is a non-read-only, non-destructive, open-world operation. The description adds useful behavioral context about the scheduling requirement and the two-feed limit per catalog, but does not cover auth needs, return behavior, or error conditions.

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 waste. The core action is stated first, and the limit is appended immediately without unnecessary phrasing.

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 create tool with a nested data object and no output schema, the description gives a key business limit but omits authentication requirements, response expectations, and fuller field-level guidance, leaving the schema and annotations to carry most of 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?

Schema description coverage is only 50%, and the catalog_id parameter is undocumented in the schema. The description adds a meaningful constraint about mode ('different modes') and catalog capacity, but it does not compensate for the undocumented catalog_id or explain required data fields.

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

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

States a specific verb and resource: 'Create a scheduled product feed'. It also adds a meaningful scope constraint, but does not explicitly differentiate itself from siblings like update_product_feed or list_product_feeds, leaving that distinction to the base verb.

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

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

The constraint 'max 2 per catalog, of different modes' implies when this tool is applicable, but there is no explicit when-to-use guidance or reference to alternatives such as update_product_feed for modifying an existing feed.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the agent knows this is a non-destructive write operation. The description adds that the product set is 'filtered' and intended for catalog ad groups, but it does not disclose auth requirements, rate limits, idempotency, or what is returned. With annotations covering the safety profile, this is adequate but thin.

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, immediately conveying the action, resource, and domain. Every clause 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 create operation with a nested object, no output schema, and only 50% parameter description coverage, the description is too sparse. It leaves catalog_id semantics, filter rule syntax, and return behavior undocumented. Annotations cover safety, but an agent would still lack important invocation context.

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 50%: the nested data object is partially described, but catalog_id has no description. The description does not explain what catalog_id represents or how the filter rule string should be formatted, and the mention of 'product_set_id' is not an input parameter. It therefore fails to compensate for the schema's gaps.

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

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

The description states a specific verb and resource: 'Create a filtered product set.' It also clarifies the domain ('for catalog ad groups') and likely returned identifier ('product_set_id'). However, it does not explicitly differentiate the tool from siblings like reddit_ads_create_catalog or reddit_ads_create_product_feed, so it falls short of a 5.

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

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

The description provides no when-to-use guidance, no alternatives, and no prerequisites. It only implies usage by saying the product set is for catalog ad groups, but does not tell the agent when to choose this tool over reddit_ads_update_product_set, reddit_ads_create_catalog, or other create 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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds meaningful context — that the saved audience is reusable on ad groups via saved_audience_id — but says nothing about required scopes, whether duplicates are rejected, or idempotency.

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 purpose and the reuse mechanism are stated immediately, and nothing is wasted.

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

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

For a 2-param create tool with a fully documented schema and annotations covering the safety profile, the description is nearly sufficient; naming saved_audience_id effectively communicates the handle returned. It could mention auth/account-scope requirements, but nothing critical for invocation is missing.

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

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

Schema coverage is 100%, so the schema already documents both the nested data fields and ad_account_id default. The description mentions 'targeting configuration' generically but adds no syntax, format, or constraint detail beyond what the schema provides; baseline 3 applies.

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

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

The description states a specific verb+resource ('Save a targeting configuration') and explains the reuse purpose via saved_audience_id. It implicitly distinguishes itself from list_/get_/update_saved_audience siblings by being the creation step, but never names an alternative explicitly.

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

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

There is no when-to-use guidance, no prerequisite (e.g. that an ad account must exist), and no routing versus update_saved_audience or list_saved_audiences. The phrase 'reuse on ad groups' hints at intent but does not tell the agent when this tool is the right choice.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description earns credit for disclosing cascade behavior beyond the annotations: deleting the catalog also removes its feeds, sets and products. It does not state permission requirements or whether the action can be undone.

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, front-loaded with the verb and permanence warning, conveying both the target and the blast radius without waste.

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

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

For a one-parameter destructive tool with no output schema, the description covers the essential risk information (irreversibility plus cascade scope). It stops short of prerequisites such as required permissions or confirmation steps, but an agent can call it correctly with what is given.

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

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

Schema description coverage is 0% and the description says nothing about catalog_id, so no meaning is added beyond the schema's type/minLength. The single parameter is self-evident by name, which keeps this at the baseline rather than lower.

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

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

States a specific verb ('Permanently delete') and resource ('product catalog'), and adds the cascade scope (feeds, sets, products) that separates it from sibling deletes like reddit_ads_delete_product_feed, reddit_ads_delete_product_set and reddit_ads_delete_products. It never names those siblings explicitly, so differentiation is implied rather than spelled out.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of the narrower deletion siblings (delete_products, delete_product_feed, delete_product_set) that an agent might prefer. The cascade scope hints at the tool's role, but the agent must infer that this is the wholesale option.

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

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

Annotations already indicate destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write operation. The description adds the word 'Permanently', reinforcing irrevocability, but does not disclose other behavioral traits like rate limits, required scopes, or side effects. With annotations covering the basic safety profile, 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, front-loaded sentence that conveys the core action efficiently. It is not verbose, though it could be slightly more informative without losing conciseness.

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

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

For a destructive operation with no output schema and sparse parameter documentation, the description is insufficient. It omits critical context such as required permissions, potential side effects (e.g., impact on associated ads), and any conditions for use, leaving the agent under-informed.

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 has only one parameter (creative_asset_id) with 0% description coverage, and the tool description does not elaborate on its meaning or format. The parameter name is self-explanatory, but the description does not compensate for the lack of schema documentation, leaving semantics to inference.

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 ('Permanently delete') and resource ('creative asset from the library'), clearly indicating the operation. It is distinguishable from sibling tools like update_creative_asset or list_creative_assets, though it doesn't explicitly reference them.

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

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

No guidance is provided on when to use this tool versus alternatives or what prerequisites might exist (e.g., ownership, permissions). The description only states what it does, not when it should be invoked.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so safety is covered. The description adds only the word 'Permanently', which usefully signals non-reversibility, but it omits cascading effects, whether deletion is synchronous, or required permissions.

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 zero waste and the destructive nature signalled first. Brevity here edges toward under-specification rather than poor structure.

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

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

For an irreversible delete with no output schema and an undocumented parameter, the description should cover recoverability, prerequisites, and side effects on dependent entities. None of that is present, so an agent lacks enough to invoke it safely.

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

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

Schema description coverage is 0% for the single required parameter audience_id, and the description never mentions it. An agent gets no help on where to obtain the ID or its expected format, so the description fails to compensate for the schema gap.

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

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

States a specific verb (delete) and resource (custom audience) with the permanence qualifier. It does not differentiate from siblings such as reddit_ads_delete_catalog or reddit_ads_update_custom_audience_users, but the core action 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?

No guidance on when to use this versus updating or listing audiences, no prerequisites (e.g., audience must exist), and no note about the effect on campaigns or ad groups currently targeting the audience. 'Permanently' hints at irreversibility but stops short of actionable context.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is largely covered. The word 'Permanently' adds useful confirmation of irreversibility, but the description does not describe authorization requirements, cascading effects, or what happens to associated product sets or products.

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 or repetition. It is optimally concise, though the terseness contributes to gaps captured in other dimensions.

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

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

For a destructive, one-parameter tool with no output schema, the description is too sparse. It omits how to obtain the feed_id, permission requirements, and whether deletion cascades to related entities, leaving meaningful gaps despite annotations covering the basic destructive nature.

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 has 0% description coverage and the description does not explain feed_id at all. While the parameter name is somewhat inferable from the tool's purpose, the description fails to compensate for the missing schema documentation by stating format, source, or constraints.

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

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

The description states a specific verb and resource: 'Permanently delete a product feed.' This clearly identifies the operation, but it does not distinguish this tool from sibling deletion tools such as reddit_ads_delete_products or reddit_ads_delete_product_set, so the agent must infer scope from the name alone.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states the action without telling the agent under what conditions deletion is appropriate or which related tools to use instead.

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

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

Annotations already declare destructiveHint=true, openWorldHint=true, and readOnlyHint=false, so the safety profile is fully covered by structured data. The description adds the batch cap of 1000 and the catalog scoping, but says nothing about irreversibility, confirmation requirements, or partial-failure behavior beyond what the annotation implies.

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 zero filler. The action, scope, keying field, and limit are all packed efficiently with no wasted words.

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

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

For a two-parameter destructive delete with annotations carrying the safety profile and no output schema, the description is largely complete. It could go further in noting irreversibility or recovery, but nothing essential for correct invocation is missing.

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

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

Schema description coverage is 50%: 'data' is documented as 'Product IDs' while 'catalog_id' has no description. The description reinforces that deletion targets product IDs within a catalog, which maps both parameters, but adds no format or syntax detail beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb (delete), resource (products), scope (from a catalog), and method (by product ID), plus a batch limit of 1000. It is very clear but does not explicitly differentiate itself from related siblings such as reddit_ads_upsert_products, relying on the reader to infer the distinction from the verb.

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

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

Usage is implied by the destructive verb 'delete' within a catalog context, so an agent can reasonably infer when it applies. However, there is no explicit when-to-use guidance or reference to the alternative reddit_ads_upsert_products (which adds/updates products), leaving the delete-vs-upsert decision unstated.

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

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

The annotations already declare destructiveHint=true and openWorldHint=true, covering the basic safety profile. The description adds that deletion is permanent, which reinforces irreversibility beyond the annotation. However, it does not disclose side effects (e.g., what happens to associated products), required permissions, or any other behavioral context. With annotations present, 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, front-loaded sentence with no wasted words. It is appropriately sized for the operation and gets straight to the point.

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

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

Given the low complexity (one parameter, no output schema) and annotations that cover the destructive safety profile, the description is minimally viable. It states what the tool does, but it omits where to obtain the product_set_id and any side effects of deletion, leaving gaps for an agent to fill.

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 has one required parameter (product_set_id) with 0% description coverage. The description says nothing about the parameter, so it fails to compensate for the missing schema documentation. While the parameter name is self-explanatory, the description adds no meaning beyond the name itself.

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: 'Permanently delete a product set.' It is unambiguous and clearly distinct from sibling list/get/create/update product set tools by virtue of the delete action. However, it does not explicitly differentiate itself from siblings or name alternatives, so it falls short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The word 'Permanently' hints at caution but does not constitute usage guidance. No when-to-use context is 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?

Annotations already declare readOnlyHint and openWorldHint, but the description adds a genuine operational constraint not present in structured data: a 10-requests-per-minute rate limit. It also lists the returned metrics (impressions, clicks, conversions, reach), useful given there is 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?

Two tight sentences with the core purpose front-loaded and the rate limit appended. No filler; every clause carries information.

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

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

For a read-only estimation tool with no output schema, the description supplies the return metrics, the planning context, and the rate limit. The notable gap is sibling routing (no mention of suggest_bid/get_channel_reach despite a dense sibling set), but otherwise it is sufficient to call correctly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters and the nested data object in detail. The description adds no further parameter semantics (e.g., how objective or goal_value affects the estimate), so the baseline 3 applies.

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

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

It states a specific verb+resource ('Estimate audience size and delivery') scoped to 'a planned ad group' and enumerates the returned metrics. It does not explicitly differentiate itself from estimation-adjacent siblings like reddit_ads_suggest_bid or reddit_ads_get_channel_reach, leaving that 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?

'for a planned ad group' implies the pre-launch planning context, and the rate limit hints at intended usage, but there is no explicit when-to-use/when-not guidance and no alternative tool is named. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. Because no output schema exists, the description's enumeration of effective_status, rejection_reason, post_url and preview_url adds genuine behavioral value about what comes back.

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 front-loaded sentence with no filler. The trailing 'including ...' list is justified because it substitutes for a missing output schema, though it reads slightly as a dump.

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

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

For a read-only lookup with one required parameter and no output schema, the description covers the essential return shape. The remaining gap is the ad_id contract, which is the one thing an agent must get right to call it.

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

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

The single ad_id parameter has 0% schema description coverage, and the description never explains its format, source, or how to obtain it (e.g. from list_ads). With one undocumented parameter, the description needed to compensate and does not.

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

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

States a specific verb+resource ('Get an ad') and names the fields returned, which distinguishes it from list_ads and update_ad by name. It does not explicitly contrast with the sibling tools, but the singular 'an ad' plus the parent tool name makes the scope 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?

No when-to-use guidance, no prerequisites, and no mention of when to prefer this over reddit_ads_list_ads or reddit_ads_api_request. Usage is only implied by the retrieval 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description usefully adds what data surface is returned, but says nothing about auth requirements, the REDDIT_ADS_ACCOUNT_ID fallback behavior, or rate limits. With annotations present, a 3 is appropriate.

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 resource is named immediately and the returned fields follow inline. Every clause 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?

There is no output schema, so listing the returned fields (currency, time zone, attribution, approval status, exclusions) genuinely compensates for the missing return contract. Combined with the 100%-documented parameter and read-only annotations, the definition is nearly complete for a simple fetch 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% and the single ad_account_id parameter is fully documented in the schema (t2_/a2_ format plus the REDDIT_ADS_ACCOUNT_ID default). The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb (Get) and resource (ad account) and enumerates the returned fields (currency, time zone, attribution settings, approval status, exclusions). This clearly distinguishes it from the plural sibling reddit_ads_list_ad_accounts, though it never explicitly names that contrast.

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

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

Usage is only implied: the singular resource and field list suggest fetching one account's details, but there is no explicit statement of when to prefer this over reddit_ads_list_ad_accounts, reddit_ads_query_ad_accounts, or reddit_ads_get_ad_account_history.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already clear. The description adds some content context by specifying that the log shows 'who changed what and when.' However, it does not disclose pagination behavior, rate limits, or authentication requirements beyond what the schema already provides.

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 zero waste. It communicates the core purpose immediately and does not include 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 tool has five parameters, a nested object, and no output schema, the description is minimal but provides a basic summary of the return content. It does not explain pagination, filtering, or the default ad account behavior, though the schema covers those details. It is adequate but leaves room for more context.

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

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

Schema description coverage is 100%, so all five parameters are fully documented in the schema. The description adds no parameter-level meaning beyond what the schema provides. Baseline 3 is appropriate when the schema carries the full parameter burden.

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: 'Get the change log of an ad account.' It adds a parenthetical clarifying the content ('who changed what and when'). It does not explicitly differentiate from siblings like get_ad_account or get_report, though the resource is naturally distinct.

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 usage guidance is provided. The description does not say when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The intended use is only implied by 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the payload includes targeting, bidding and status, but discloses nothing further about permissions, failures, or completeness of the returned object.

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 or repetition. It is appropriately terse, though the terseness is partly a symptom of missing detail rather than disciplined editing.

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-object read with safety annotations, the description is nearly adequate and even sketches the returned fields, which helps since no output schema exists. However it leaves the required parameter undocumented and gives no error or edge-case context.

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

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

Schema description coverage is 0% and the description does not mention ad_group_id at all, providing no meaning for the sole required parameter. The parameter name is fairly self-explanatory, but the description fails to compensate for the coverage gap.

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

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

States a specific verb and resource ('Get an ad group') and enumerates the content returned (targeting, bidding, status). It is clearly distinguishable from list_ad_groups/create_ad_group/update_ad_group by implication, but never names or contrasts siblings explicitly.

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

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

No when-to-use or when-not-to-use guidance, no prerequisites (e.g., needing a valid ad_group_id), and no routing to alternatives like list_ad_groups. The single-object read context is only implied by the name and title.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only a restatement of the core retrieval purpose and discloses no additional behavioral traits such as return shape, pagination, latency, or authentication requirements.

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

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

A single sentence with no filler, front-loading the action and the scope. Every word contributes to the purpose statement.

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

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

For a simple one-parameter read-only tool with annotations covering safety, the description adequately states what is returned. However, it omits any pointer to where app_id comes from and lacks usage context, leaving clear gaps for an agent trying to invoke it independently.

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

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

Schema description coverage is 0%, so the description carries full burden for the single required app_id parameter. It only implies that an app is involved via 'for an app' and gives no format, source, or identification guidance for the app_id 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?

States a specific verb ('Get when...last fired') and resource ('each mobile conversion event...for an app'). This effectively distinguishes it from the sibling reddit_ads_get_pixel_last_fired by scoping to app events rather than pixels, but it does not explicitly name or contrast with any 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?

The description gives no when-to-use guidance, no prerequisites, and no alternatives. It does not mention that this is for mobile app conversion events as opposed to pixel events, nor when to prefer it over reddit_ads_list_apps or reddit_ads_get_pixel_last_fired.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. Beyond that the description adds nothing: no note on auth requirements, behavior when the ID is unknown, or what the lookup returns. It does not contradict annotations, but it contributes no extra behavioral context.

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

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

A single short sentence with the key qualifier front-loaded and no filler. It is efficient, though arguably under-specified rather than optimized, which keeps it just under the top mark.

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

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

For a single-parameter lookup with no output schema, the description should hint at the returned business shape or list_businesses as the way to discover IDs. Neither appears, so an agent knows what to pass but not how to get it or what comes back.

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

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

Schema description coverage is 0% for the single required parameter, so the description carries the full burden. 'by ID' only implies the argument is an identifier, adding minimal meaning over the business_id field name, and gives no format or source hint (e.g., where to obtain the ID).

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

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

States a specific verb (Get) and resource (a business) with the retrieval mechanism (by ID). It is clear on its own, but it never distinguishes itself from the sibling list_businesses or update_business, so it does not reach the sibling-differentiation bar for a 5.

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

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

The description provides no when-to-use context, no prerequisites, and no indication of when to prefer this over list_businesses or update_business. It is a bare capability statement with no 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?

readOnlyHint=true already tells the agent this is a safe read, so the description's burden is lower. It adds modest value by naming effective_status and delivery_status as the notable returned fields, but says nothing about failure modes (e.g., behavior for a non-existent campaign_id) or return shape beyond those two fields.

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 efficient sentence with the core action front-loaded and the notable output fields appended. No filler, though it is so terse that it leaves obvious questions unaddressed.

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

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

For a simple one-parameter read tool with no output schema and a readOnlyHint annotation, the definition is minimally adequate. It hints at returned fields but omits any guidance on identifier source or error/empty-result behavior, leaving it just viable rather than 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?

There is a single parameter, campaign_id, with 0% schema description coverage, so nothing in the structured data explains its format. The description does not clarify it either, though its meaning is largely self-evident from the name. Slight gap keeps this at baseline rather than higher.

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

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

States a specific verb (Get) and resource (campaign) and even names two fields returned (effective_status, delivery_status). This lets an agent distinguish it from list_campaigns, create_campaign, and update_campaign. It stops short of explicitly contrasting with its siblings, so it is clear but not fully differentiated.

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

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

There is no guidance on when to use this versus reddit_ads_list_campaigns or reddit_ads_update_campaign, nor any stated prerequisite (e.g., owning/accessing the campaign). Usage is only implied by the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safe-read profile is covered. The description adds nothing beyond that — no note on authorization requirements, what the catalog object contains, or whether the lookup can fail for missing IDs. It does not contradict the annotations, but contributes no behavioral context.

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

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

One short sentence with no waste, but this is under-specification rather than conciseness. Brevity here comes at the cost of any useful 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 retrieval tool with no output schema and a 0%-documented required parameter, the description should describe the returned catalog and the identifier's source. None of that is present, so an agent has insufficient information 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 description coverage is 0%, so catalog_id is documented nowhere. The description does not explain what a catalog_id is, where to obtain it, or its format, which is exactly the gap it should fill for a single required identifier.

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 'Get a product catalog' merely restates the tool name and title with no additional specificity. It does not distinguish this tool from siblings like reddit_ads_list_catalogs, reddit_ads_get_product_feed, or reddit_ads_list_catalog_products, so an agent gets no signal about what makes this retrieval distinct.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative. The agent cannot tell from the text when to call get_catalog versus list_catalogs or get_product_feed, leaving routing entirely to inference from the tool name.

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

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

The readOnlyHint/openWorldHint annotations already cover the safety profile, so the description's job is to add behavior. It usefully states that the result is a download URL rather than inline data, but says nothing about URL expiry, report contents, or async job state.

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

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

One short, front-loaded sentence with no filler. It is efficient, though perhaps overly terse given the unaddressed parameter and return-value questions.

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

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

With no output schema, the description partially compensates by naming the download URL as the payload, which is the key return detail. But it omits what the report covers and where import_id comes from, leaving gaps for a task that must be chained after listing imports.

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

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

Schema coverage is 0% and the single parameter 'import_id' is undocumented in both schema and description. The description never explains that import_id identifies the feed import whose report is fetched, so the agent gets no help mapping the parameter to behavior.

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?

Clear verb+resource (get ... catalog import report) and it specifies the return shape ('a download URL'). It distinguishes the tool from list siblings like reddit_ads_list_catalog_imports, though it doesn't explicitly contrast with reddit_ads_list_catalog_import_issues.

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 or when-not-to-use guidance. Nothing tells the agent how this differs from reddit_ads_list_catalog_imports or reddit_ads_list_catalog_import_issues, or under what condition a report URL is needed.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the scope (Reddit-wide) and output concept (reach curve, impressions vs reach), which is useful given no output schema, but omits auth needs, rate limits, and output 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?

A single front-loaded sentence with no wasted words. It states the purpose immediately and is appropriately sized for the information it currently provides.

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 five parameters, zero schema description coverage, and no output schema, the description is too thin. It gives a high-level output concept but omits parameter explanations, usage guidance, and return details that an agent would need for confident invocation.

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

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

Schema description coverage is 0% and the description mentions none of the five parameters (duration_days, geolocation, gender, min_age, max_age). It does not compensate for the schema gap or add any meaning beyond the raw enum and type definitions.

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

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

States a specific verb (Get) and resource (Reddit-wide reach curve) with the output form (impressions vs reach) and purpose (media planning). It is clear, but does not distinguish itself from similar planning tools like reddit_ads_estimate_audience or reddit_ads_suggest_bid.

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 media planning' implies usage context, but there is no explicit when-to-use, when-not-to-use, or alternative selection guidance. An agent would need to infer that this is for planning reach rather than audience estimation or bid suggestions.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that results include subscriber counts and categories and that matching is exact, but says nothing about rate limits, auth requirements, or pagination behavior beyond what the schema documents.

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 matching mode is stated first and the useful return fields follow. Nothing needs trimming.

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

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

For a read-only lookup tool with full schema coverage and no output schema, the description covers the key facts an agent needs: what it matches on and what comes back. Pagination/merge behavior is only in the schema, which is an acceptable minor 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%, including the 'comma separated subreddit names without r/' format and pagination semantics, so the baseline is 3. The description's 'exact name' phrasing reinforces the names parameter but adds no syntax detail beyond the schema.

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

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

States a specific verb (look up), resource (subreddits), and constraint (exact name), plus the returned fields (subscriber counts and categories). The 'exact name' qualifier implicitly separates it from search_communities/suggest_communities, though it never names them outright.

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 'exact name' constraint implies this is the lookup path when you already know the subreddit name, but the description never states when to use it over reddit_ads_search_communities or reddit_ads_suggest_communities, nor any prerequisite. Usage is inferred, not stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that—no note on what the asset payload contains, whether ids are global or account-scoped, or any 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?

The sentence is short but that is under-specification rather than conciseness—it conveys no information beyond the title, so the brevity does not 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?

With no output schema and no parameter documentation, the description would need to carry the load, but it says nothing about return values, id source, or usage context. Inadequate for even a simple single-parameter retrieval 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?

There is one required parameter (creative_asset_id) with 0% schema description coverage, and the description provides no information about its format, origin, or where to obtain it. The description fails to compensate for the schema gap.

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?

"Get a creative asset" simply restates the tool name and title with no added specificity. It does not distinguish this fetch-by-id tool from siblings like reddit_ads_list_creative_assets, reddit_ads_get_creative_asset_upload, or reddit_ads_update_creative_asset.

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, no prerequisites, and no mention of alternatives. The agent must infer that this retrieves a single asset by id versus the list variant.

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?

readOnlyHint=true already establishes the safe-read profile, so the description's job is to add context. It does disclose the returnable status values (PROCESSING_MEDIA|ACTIVE|INVALID_MEDIA) and that an asset is produced, which is genuine added value, but it says nothing about read timing, eventual consistency, or auth requirements.

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

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

One compact sentence with the resource front-loaded and the return shape trailing. Every clause carries information; no filler.

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

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

For a read-only, single-parameter lookup with no output schema, the description does the important work of naming the possible status states, but it omits what the id refers to and when in the upload lifecycle the call is appropriate. Adequate but with a clear 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 0% and the single required parameter 'id' carries no description anywhere. The description never clarifies that the id is an upload id (as opposed to an asset id), which is the key ambiguity given the nearby get_creative_asset sibling.

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

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

States a specific verb+resource ('Get a creative asset upload') and goes further by naming what is returned (status enum and resulting asset). It is distinguishable from list_creative_asset_uploads and get_creative_asset by resource, though it doesn't explicitly contrast with those siblings.

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

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

The description only says what the tool returns; it never says when to call it. There is no hint that this is the polling tool to use after reddit_ads_upload_creative_assets, nor any exclusion against list_creative_asset_uploads. Usage must be inferred entirely from context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that the response includes status and size, which is useful since there is no output schema, but it says nothing about auth requirements, error conditions (e.g. invalid audience_id), or ownership scoping.

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

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

A single front-loaded sentence with no filler; the key noun and the returned fields come first. Nothing is wasted.

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

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

For a simple read-only lookup with one parameter, the description is minimally adequate and even hints at the return payload. It stops short of explaining how to obtain audience_id or what a failed lookup yields, which an agent would need.

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 single parameter audience_id has 0% schema description coverage and the description never mentions it, so there is no indication of its format, source, or whether it is the numeric Reddit ID or a prefixed string. With low coverage the description was expected to compensate and does not.

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

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

States a specific verb ('Get') and resource ('custom audience') and even names the fields returned (status and size). It is clearly distinct from reddit_ads_list_custom_audiences, create/delete/update siblings by virtue of the singular retrieval, though it never explicitly contrasts itself with them.

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

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

No guidance on when to use this versus reddit_ads_list_custom_audiences or the other custom-audience siblings, and no prerequisites or context are given. The agent must infer usage from the 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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds real value by enumerating the possible job states (QUEUED|COMPLETED|FAILED), which is not present in the schema or annotations, but it omits polling expectations, what a FAILED state implies, and any 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 short sentence that leads with the verb and resource and appends the enumeration inline. Nothing is wasted and nothing is buried.

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 safety annotations, the core is covered, and the status enumeration partially compensates for the missing output schema. However, the origin of job_id and the polling workflow are absent, which an agent needs to use this tool correctly in sequence.

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

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

Schema description coverage is 0% for the single job_id parameter, so the description must compensate and does not. It never explains where job_id comes from (presumably the create_data_deletion_job response) or its format, leaving the agent to infer this.

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

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

States a specific verb (Get) and resource (data deletion job), and the parenthetical enumerates the possible statuses, which sharpens what 'status' means. It does not explicitly contrast with siblings like reddit_ads_create_data_deletion_job, but the verb/resource pair is unambiguous enough that an agent can separate read-status from job creation.

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

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

No when-to-use guidance is given. It never says to call this after create_data_deletion_job to poll progress, never mentions whether polling is expected or how often, and doesn't name any alternative for other job types (e.g. get_poster_job, get_post_job). The usage is only implied by the noun.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds nothing beyond that — no note on what the form object contains, whether the ID must belong to the authenticated business, or any error conditions.

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 very short sentence that is under-specified rather than efficient. It avoids waste but says too little to be considered well-structured for a retrieval 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?

With no output schema and a bare description, an agent cannot know what fields come back or how to source the ID. For a read tool operating in a large sibling set, this is insufficient context.

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

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

Schema description coverage is 0%, so the single parameter lead_gen_form_id is documented only by its name and type. The description does not explain the ID format, where to obtain it, or that it must reference an existing form, leaving the schema to carry the full burden inadequately.

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 'Get a lead generation form' essentially restates the tool name and title without adding substance. It does not distinguish this retrieval tool from siblings like reddit_ads_list_lead_gen_forms or reddit_ads_create_lead_gen_form, nor does it clarify what 'getting' returns.

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

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

No guidance on when to use this tool versus the sibling list_lead_gen_forms or the create variant. The agent must infer that a valid lead_gen_form_id is needed and that this is a single-record lookup.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description does add one useful behavioral nuance beyond the structured fields: the return may be a member OR a system user, implying an authentication context and a variable entity type. It says nothing about auth failure behavior or what fields come back.

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 with no filler, front-loaded with the verb and the exact resource. Nothing could be removed without losing 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 read with readOnlyHint and openWorldHint already declared, the definition is nearly sufficient. The only mild gap is that no output schema exists and the description does not sketch the shape of the returned member/system-user object, though this is a minor omission for a simple identity lookup.

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

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

The tool takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The absence of arguments is itself consistent with a 'get current identity' operation, which the description implies.

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

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

States a specific verb and resource: 'Get the authenticated Reddit Ads member or system user,' which tells an agent this returns the identity of whoever is currently logged in. It is distinguishable from peers like get_business or get_ad, though it never explicitly contrasts itself with the adjacent reddit_ads_auth_status or reddit_ads_get_profile 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?

There is no when-to-use guidance, no mention of prerequisites (e.g., must be logged in), and no routing to alternatives such as reddit_ads_auth_status for a lighter-weight auth check or reddit_ads_get_profile for profile data. Usage is only implied by the tool name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds that results are per conversion event, but does not describe return shape, ordering, or pagination — modest added value against the lower bar set by annotations.

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

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

A single tight sentence with the action and scope front-loaded and zero filler; every phrase earns its place.

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

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

For a one-parameter read-only tool with no output schema, the description conveys both the operation and the conceptual return (last-fired times per conversion event) plus the diagnostic intent. Only minor detail about the result structure is absent.

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 schema description coverage at 0% for the single pixel_id parameter, the description is the only source of meaning, and it only implies that a pixel identifier is supplied ('for a pixel'). It adds no format, source, or lookup guidance beyond that implication.

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

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

States a specific verb (Get) and resource (when each conversion event last fired for a pixel), with scope clear enough to distinguish the pixel variant from the parallel reddit_ads_get_app_last_fired. It does not explicitly name that sibling, so it falls just short of 5.

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

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

The clause 'to check tracking health' supplies a usage context, implying this is a diagnostic tool. However, there is no explicit when-to-use/when-not guidance and no reference to alternatives, so the guidance remains implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no further behavioral context — nothing about authentication requirements, error behavior for invalid/missing IDs, or rate limits — so it contributes essentially nothing beyond the structured fields.

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

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

A single short sentence with zero filler, and the identifier format is front-loaded immediately after the purpose. Appropriately sized for a one-parameter read 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 simple read-only lookup with annotations covering safety and only one required param, the description is minimally sufficient. However, with no output schema and a large set of overlapping post/structured-post siblings, it leaves the agent without enough to reliably choose this tool over its neighbors.

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

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

Schema description coverage is 0% and the single post_id parameter is undocumented in the schema, so the description must compensate. It partially does so by giving the t3_ prefix format, but it never clarifies whether the full fullname or a bare ID is required, nor what happens on an unknown ID.

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

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

States a clear verb+resource ("Get a post by ID") and adds the Reddit fullname prefix convention (t3_...), which tells an agent what kind of identifier it is. It does not distinguish itself from the sibling reddit_ads_get_structured_post or explain how a post differs from a structured post, so it falls short of full sibling differentiation.

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

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

There is no when-to-use guidance, no prerequisites (e.g. auth), and no mention of the obvious alternatives such as reddit_ads_list_posts for discovery or reddit_ads_get_structured_post. The agent must infer usage entirely from the tool name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds useful value by naming the two return contents (status and generated posters), which matters because there is no output schema, but it says nothing about polling cadence, terminal job states, or permissions.

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 tight sentence with no filler and the key return contents front-loaded. Appropriate length, though it could be expanded slightly to earn more 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?

There is no output schema, so the description carries the return-value burden; it discloses the two payload categories but not the state model (e.g., pending/complete/failed) or how to obtain the job id. Adequate but with clear gaps for a job-status tool.

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

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

Schema description coverage is 0% for the single required 'id' parameter, and the description never clarifies that this is the poster job id obtained from create_poster_job. With only one opaque parameter, the description should compensate but does not.

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

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

States a specific verb ('Get') and resource ('poster generation job') plus the payload (status and generated posters). It is distinguishable from create_poster_job, though it does not explicitly disambiguate itself from the near-named sibling get_post_job.

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

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

No guidance on when to call this versus alternatives, and it omits the obvious workflow context: that this is the polling companion to create_poster_job (call create first, then poll this with the returned id).

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

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

Annotations declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds real value by disclosing the status enum and the returned post_id. It does not say whether CLIENT_ERROR/SERVER_ERROR are terminal or whether polling is expected, which is the main remaining 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?

One sentence, front-loaded with the action and resource, and the enum is packed inline with no wasted words.

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

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

With no output schema, the description usefully names what comes back (status plus post_id), and annotations cover the read-only nature. It is nearly complete for a polling tool, missing only guidance on terminal states and polling cadence.

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

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

Schema description coverage is 0% for the single post_creation_job_id parameter, and the description only references the job generically. The parameter's origin (from create_post_job) and format are left to inference, but the single obvious param keeps this adequate.

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

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

States a specific verb (Get) plus resource (structured post creation job) and even enumerates the possible status values returned. An agent can distinguish this from the sibling create_post_job and get_poster_job without opening the schema.

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

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

Usage is implied: this is clearly a poller for a job returned by create_post_job, and retrieving the resulting post_id confirms that intent. However, it never states when to call it, how often, or that it should be used after create_post_job rather than get_structured_post.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered externally, but the description adds nothing on top — it does not say whether the feed is fetched live from the remote source, whether missing feeds error or return null, or anything about latency/auth. It contributes zero behavioral signal.

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

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

It is a single grammatical sentence with no filler and is front-loaded, but its brevity reflects under-specification rather than disciplined concision — there is no meaningful content being compressed.

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

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

A read-only single-item fetch with no output schema and no annotation detail about returns leaves the agent without any picture of what a 'product feed' object contains or how to obtain a valid feed_id. For a tool in a dense catalog/feed tool family, this is materially incomplete.

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

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

One required parameter (feed_id) with 0% schema description coverage, so the description carries the full burden and provides nothing — no identifier format, no hint where feed_id comes from (list_product_feeds / create_product_feed). The parameter name is self-evident, which is the only reason this is not a 1.

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 sentence 'Get a product feed' is a verbatim restatement of the tool name reddit_ads_get_product_feed; it adds no scope, no distinguishing detail versus siblings like reddit_ads_list_product_feeds or reddit_ads_get_catalog. This is the textbook tautology case.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g. an existing feed_id from reddit_ads_list_product_feeds or reddit_ads_create_product_feed), and no exclusions relative to the ~100 sibling tools. The agent must infer everything from the 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?

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is already covered. The description adds nothing on top of that — no note about scoping, permissions, or what a retrieved product set represents, so it contributes essentially zero behavioral context.

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

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

The single sentence is terse and front-loaded, but it is under-specified rather than concise — it wastes its one sentence restating the name instead of conveying anything useful.

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

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

For a read-only lookup tool with no output schema and one undocumented parameter, the description should at minimum explain what a product set is and how the ID is obtained. Neither is present, so it is incomplete for correct invocation.

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

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

Schema description coverage is 0%, so the schema only supplies a required string named product_set_id with no format or provenance. The description says nothing about the parameter, leaving the agent without guidance on where the ID comes from or how it should look.

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 'Get a product set.' merely restates the tool name and title, adding no information beyond the verb+resource already implied. It does not distinguish this retrieval tool from siblings like reddit_ads_list_product_sets or reddit_ads_list_product_set_products.

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, what prerequisite steps are needed to obtain a valid product_set_id, or how it relates to the sibling list/create/update/delete product set tools. Usage must be inferred entirely from the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered externally. The description adds nothing beyond that: no note on auth requirements, what a profile contains, or behavior when the ID does not exist.

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, which is appropriate structurally. It reads as under-specification rather than genuine conciseness given how little it 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?

For a simple read tool this is close to the minimum, but with no output schema and no description of the returned profile shape, or which entity a 'profile' is, the agent cannot confidently call it against the right sibling.

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

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

Schema coverage is 0% and the single required parameter carries only minLength. 'By ID' echoes the schema field rather than explaining the identifier's format, source, or valid values, so the parameter remains semantically thin.

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

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

States a verb ('Get'), resource ('Reddit profile'), and shards out the key ('by ID'), so the basic action is legible. However, 'profile' is ambiguous in this API family, which also exposes get_me, list_account_profiles and list_business_profiles, and the description offers no differentiation from those.

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 context, no alternative named, no prerequisites. With several sibling tools returning profile-like data, the agent is left to guess which one applies.

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

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

Annotations already declare readOnlyHint and openWorldHint, but the description adds genuinely non-obvious behavior: metric keys return lowercase, specific fields are micro-currency (divide by 1,000,000) while conversion_*_total_value is in cents, and data can take up to 6 hours to settle. These are high-value operational facts an agent cannot get from the schema. It stops short of covering pagination behavior despite max_pages/page_size params.

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

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

Three sentences, front-loaded with the purpose, then the most failure-prone details (units, lowercase keys, settlement lag). The currency sentence is dense but every clause maps to a real integration pitfall. No filler.

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

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

For a complex 12-parameter reporting tool with no output schema, the description covers the return-value semantics that would otherwise be missing (units, key casing, freshness). The remaining gaps — pagination and filter/breakdown constraints — are documented in the schema, so the agent is not left blind.

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 83%, so baseline is 3. The description adds meaning beyond the schema by explaining the return-side semantics of the fields parameter (lowercase output keys, currency units per metric family), which the schema does not document. It does not add anything about filter, breakdowns, or pagination syntax.

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

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

States a specific verb and resource: 'Get performance metrics for an ad account.' An agent can tell this is the reporting/analytics tool rather than a list/get-entity tool. It does not explicitly differentiate itself from adjacent read siblings (e.g., get_ad_account_history), but the resource 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?

No when-to-use guidance, no prerequisites, and no named alternatives. The agent must infer that this is the metrics-retrieval tool from the name alone. Nothing states when to prefer it over other query/history tools.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — no note on auth requirements, whether a missing ID errors, or what the returned audience object contains.

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 single sentence is front-loaded and free of waste, but it is concise at the cost of being under-specified rather than genuinely 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?

No output schema exists and annotations only cover the read-only/open-world nature, so the description should carry the burden of explaining what is returned. For a getter tool keyed on an opaque ID, the definition leaves too much unstated.

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

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

Schema description coverage is 0% with one required parameter (saved_audience_id), and the description says nothing about its format, provenance, or how to obtain it (e.g., from list_saved_audiences). It fails to compensate for the undocumented 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 'Get a saved audience' merely restates the tool name and title without adding scope, distinguishing it from list_saved_audiences, get_custom_audience, or get_structured_post. It is a tautology rather than a specific statement of what is retrieved or how.

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 siblings like list_saved_audiences (to enumerate) or get_custom_audience (a different audience type). No prerequisites, no exclusions, no context of any kind.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the iOS scope and the three categories of returned data (campaign, ad group, quota), which is modestly useful, but it says nothing about auth requirements, rate limits, or the meaning of 'quota'.

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. It is efficient, though its brevity is partly a symptom of under-specification rather than disciplined concision.

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

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

With no output schema, 0% parameter coverage, and three parameters, the description leaves the agent without parameter semantics or any sense of the return shape. It is too thin for the complexity of the call despite the annotations covering safety.

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

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

Schema description coverage is 0% for three parameters, so the description must carry the burden, yet it never names app_id, ad_group_id, or campaign_id. It loosely gestures at 'campaign' and 'ad group' but gives no format, required/optional distinction, or scoping semantics.

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

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

The description states a specific verb ('Get') and resource ('SKAdNetwork campaign, ad group and ad quota'), and no sibling tool overlaps with SKAdNetwork, so it is distinguishable. It is slightly fuzzy on what 'availability' concretely resolves to, but the scope (iOS app) is 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 on when to call this versus alternatives, prerequisites, or the condition that makes SKAdNetwork availability relevant. The agent is told what the tool returns but not when it is the right choice.

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

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

Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: it does not clarify return shape, whether the id refers to a structured post in the same namespace as regular posts, or error behavior for a missing/invalid id. With the lower bar set by annotations, this is still a bare minimum.

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 single short sentence is not concise so much as under-specified; it is a tautology of the title with no informational payload. Brevity here reflects missing content rather than efficient structure.

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 lookup tool with no output schema, a 0%-covered parameter, and no behavioral detail, the description leaves the agent without enough information to call it correctly. Nothing describes what is returned or how errors are surfaced.

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

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

Schema description coverage is 0% and the single parameter post_id is undocumented in both schema and description. The description does not state the id's format, source, or whether it is the structured post id returned by list_structured_posts, so it fails to compensate for the coverage gap.

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 'Get a structured post.' is a verbatim restatement of the title and tool name, adding no distinguishing detail. It does not differentiate this tool from siblings like reddit_ads_get_post, reddit_ads_list_structured_posts, or reddit_ads_update_structured_post, leaving the agent to infer what a 'structured post' actually is.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g., authentication or lookup of an existing post id), and no routing to alternatives such as list_structured_posts for discovery or get_post for regular posts. Usage is only implied by the word 'Get'.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the meaningful scoping detail that only 'approved' domains are returned, but otherwise adds little behavioral context (no pagination, filtering, or return shape).

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

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

A single tight sentence with the key qualifier ('approved') front-loaded and no wasted words. Well-matched to a no-param list 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?

With no output schema and no parameters, the description carries the full burden of explaining what comes back. It says 'tracker domains' but doesn't describe the structure or scope (e.g., per-account vs. global), leaving a modest gap for an otherwise simple 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?

There are zero parameters, so the baseline is 4. The description correctly implies no input is needed, and there are no parameters to document.

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

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

The description states a specific verb (List) and resource (approved click and impression tracker domains), plus the ad event_trackers scope. No sibling tool covers trackers, so an agent can distinguish it, though it doesn't explicitly contrast with the closest list 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?

It describes what the tool returns but gives no guidance on when to use it versus alternatives, nor any prerequisites (e.g., needing a business/account context). Usage is only implied by the noun 'approved.'

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds only that results are profiles usable for posting ads; it says nothing about scoping to the account, auth requirements, or whether an empty list is possible.

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

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

Two short sentences, no filler, with the core purpose front-loaded and the downstream rationale second. Nothing to trim.

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

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

No output schema exists, and the description does name the return content (profiles as t2_ user IDs) and its purpose. Combined with fully covered pagination params and read-only annotations, this is nearly sufficient; only explicit sibling disambiguation is missing.

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

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

Schema description coverage is 100% and pagination params (max_pages, page_size, page_token) are fully documented in the schema. The description only reinforces the t2_ ID concept, adding no format or syntax detail beyond what the schema already provides, so the baseline 3 applies.

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

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

States a specific verb (List) and resource (Reddit profiles / t2_ user IDs) scoped to an ad account, which is clearly distinct from reddit_ads_get_profile (single) . It does not explicitly distinguish itself from the sibling reddit_ads_list_business_profiles, which is the nearest 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 gives downstream motivation ('Profile IDs are needed for posts, creative assets and ads'), which implies why an agent would call it, but never says when to prefer this over reddit_ads_list_business_profiles or what prerequisites exist. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety and open-world profile is covered. The description adds only the 'grouped by business' shape hint; it says nothing about pagination, result volume, or ordering. With annotations carrying the safety burden, this is an adequate but not rich disclosure.

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

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

Two tight sentences with the resource/scope claim front-loaded and the actionable 'start here' guidance second. Nothing is wasted.

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

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

For a zero-param, read-only list tool whose annotations already cover safety and open-world behavior, the description covers what it returns and when to reach for it. Without an output schema it could say more about pagination or ordering, but nothing essential for correct invocation is missing.

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

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

The tool takes no parameters, so there is no parameter semantics to convey; the baseline for zero-param tools is 4. The description does not need to compensate for any schema gap.

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?

A specific verb and resource are stated ('List every ad account'), and scope is clarified ('the authenticated user can access, grouped by business'), which implicitly separates it from the business-scoped sibling. It stops short of naming an alternative like reddit_ads_list_business_ad_accounts or reddit_ads_query_ad_accounts explicitly.

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

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

'Start here to find ad_account_id values' gives a clear entry-point condition that tells an agent when this tool is the right first call. There is no explicit exclusion or named alternative for when a business-scoped or query variant is preferable.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so the description does not need to restate read-only safety. However, it adds no behavioral context beyond that, such as pagination merging behavior, authentication requirements, or how results are scoped beyond the ad account.

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. It is appropriately terse for a simple list operation, though its extreme brevity leaves other dimensions underspecified.

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

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

For a read-only list tool with rich schema coverage and annotations, the description gives the core action and scope. It is minimally adequate, but it does not help the agent decide when to use it or understand pagination behavior beyond what the schema already provides.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the input schema. The description adds no parameter-level meaning, which fits the baseline of 3 when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('List ad groups') and scopes it to an ad account, which distinguishes it from get_ad_group, create_ad_group, and update_ad_group. It does not explicitly contrast with sibling list tools, but the resource is clear enough for selection.

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

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

There is no guidance on when to use this tool versus alternatives such as get_ad_group or list_campaigns, nor are prerequisites or exclusions stated. The implied usage is only that it lists ad groups.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds a useful behavioral detail about filter combination logic (OR within a parameter, AND across parameters), but it does not disclose return format, pagination behavior, or rate limits.

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

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

The description is two sentences, front-loads the primary action, and every word earns its place. It efficiently conveys the core purpose and the filter combination rule 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 9-parameter schema with full documentation and annotations covering safety, the description is largely sufficient for an agent to call the tool. It omits any description of return values or pagination summary, but the schema itself documents pagination parameters thoroughly.

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, but the description goes beyond the schema by explaining how multi-value array filters combine: OR within a parameter and AND across parameters. This is meaningful semantics not present in the individual parameter descriptions.

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

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

The description states a specific verb and resource ('List ads') and scopes it to 'in an ad account,' which clearly distinguishes it from create_ad, update_ad, and get_ad. However, it does not explicitly name sibling alternatives or clarify when this is preferred over related listing tools like list_ad_groups.

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 no explicit when-to-use or when-not-to-use guidance, and it does not mention alternatives such as get_ad for a single ad or list_ad_groups for ad group listings. The purpose is implied by the verb 'List ads,' but there is no routing context.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful scope ('past campaigns'), but does not mention pagination behavior, result format, or auth requirements beyond what the schema already implies. It adds modest context without contradicting annotations.

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

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

A single, front-loaded sentence with no wasted words. The core action and scope are stated immediately.

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

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

For a simple read-only list tool with full schema coverage and no output schema, the description supplies the essential scope. It could be slightly more complete by noting pagination behavior or lack of filtering, but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema. The description adds no parameter-level meaning beyond what is structured. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: 'List mobile apps used in the ad account's past campaigns.' It is clear what the tool returns, but it does not distinguish itself from nearby siblings such as reddit_ads_get_app_last_fired. No explicit sibling routing is provided.

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 only a purpose statement, not usage guidance. It does not say when to choose this tool over alternatives, what prerequisites exist (e.g., ad account access), or any exclusions. An agent must infer the usage context.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds the ownership filter as behavioral context, but does not mention authentication requirements, rate limits, or pagination behavior beyond what the schema provides.

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

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

The definition is a single sentence with zero wasted words. The ownership scope is front-loaded and immediately useful.

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

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

For a simple read-only list tool with annotations and mostly documented parameters, the description defines scope well enough. It does not mention pagination or filtering behavior, but the schema and annotations cover those operational details.

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 80%, so the schema already documents most parameters. The description only implies business ownership filtering and does not add meaning for ids, max_pages, page_size, or page_token beyond the schema text.

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

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

The description states a specific verb (List), resource (ad accounts), and ownership scope (owned by a business, not shared into it). It distinguishes the tool from sibling list_ad_accounts and query_ad_accounts by clarifying the ownership boundary.

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

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

It gives clear context for when to use the tool and explicitly excludes shared accounts ('not those shared into it'). However, it does not name an alternative tool for listing shared accounts, so the routing guidance is useful but not fully explicit.

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

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

annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the meaningful detail that results are scoped to the authenticated user's memberships, but says nothing about authorization requirements for the role filter, pagination behavior, or result ordering. With annotations carrying the safety burden, this is an adequate but thin addition.

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 zero filler; every word earns its place and the resource and scope appear immediately.

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

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

For a 5-parameter list tool with no output schema and no required parameters, the definition is only minimally sufficient: it never indicates what a business record contains or how pagination merges (max_pages) behaves across pages. Acceptable to invoke, but the agent is left guessing about return shape.

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 80%, so the baseline is 3. The description adds no parameter detail at all — notably the 'role' enum (BUSINESS_ADMIN/CATALOG_ADMIN) is undocumented in both schema and description, but the four pagination/filter parameters are reasonably explained by the schema itself.

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

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

States a specific verb ('List') and resource ('businesses') with a clear scope qualifier ('the authenticated user belongs to'), which separates it from the singular reddit_ads_get_business. It does not, however, explicitly distinguish itself from adjacent siblings such as reddit_ads_list_business_ad_accounts or reddit_ads_list_business_profiles.

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 defines the result set but gives no when-to-use guidance, no prerequisites, and no mention of when to prefer get_business or another sibling. An agent must infer the calling context entirely.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that: no note on pagination, result merging, or what a 'business pixel' record contains, even though the schema exposes pagination controls.

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 or repetition. It is economical, though the extreme brevity borders on under-specification rather than optimal structure.

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 four-parameter, paginated list tool with no output schema and no documentation of the required business_id, this one-sentence description leaves the agent without return-shape, pagination, or scoping detail. It should do more given the structured fields do not cover everything.

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 75%, so most parameters are documented inline (max_pages, page_size, page_token). The description contributes almost nothing beyond implying business_id identifies the business, and the required business_id has no schema description, so it remains under-explained.

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

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

States a specific verb (list) and resource (Reddit pixels) plus a scope qualifier ('of a business'), which separates it from the generic sibling reddit_ads_list_pixels. It does not explicitly name that sibling or explain the distinction, so it stops short of a 5.

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

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

The only usage signal is the implicit 'of a business' scoping; there is no statement of when to choose this over reddit_ads_list_pixels or the other pixel tools (get_pixel_last_fired, create_pixel_data_deletion_job). No prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered by structured data. The description adds only the ownership scoping; it says nothing about pagination defaults (max_pages default 1) or how results merge across pages, though the schema partially covers those parameters.

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

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

A single front-loaded sentence with zero filler. It is efficient but arguably under-specified rather than maximally concise, since a scoping/alternative clause could be added at little cost.

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

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

For a read-only list tool with annotations and a partially documented schema, this is minimally adequate. Lacking an output schema, the description could state the shape of returned profiles or pagination behavior, and it does not distinguish itself from sibling profile-listing tools.