Zernio

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

The annotations already establish a read-only, non-destructive operation, so the description adds no additional behavioral context. It does not disclose pagination, object scope, ordering, or what the returned groups represent.

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

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

The description is short, but it is under-specified rather than helpfully concise. The word 'groups' is ambiguous and relies entirely on the tool name to clarify the resource being listed.

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

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

The description omits the central semantic point that this refers to account groups, and it offers no context to navigate the large sibling-tool list. The lack of parameters and the output schema aid invocation, but selection and understanding are still poorly supported.

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

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

The tool has zero parameters and the input schema is empty, so the description cannot add meaningful parameter semantics. With zero parameters, the baseline is 4, and there is no parameter-information 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?

Tautological: description restates name/title.

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 the many sibling list operations such as accounts_list or profiles_list. The description gives no context, prerequisites, or alternatives for choosing this operation.

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 establish this is read-only, and the description adds useful behavioral context beyond that: it returns only the username and ID for the first matching account, which is a non-obvious selection behavior. It does not contradict the annotations.

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

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

The description is two short sentences, front-loaded with the main purpose and then the concrete return behavior. Every sentence adds meaningful information with no filler.

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

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

For a single-parameter protected tool with an output schema and read-only annotations, the description is largely complete. The only minor gap is left unspecified what happens when no account matches the platform, but this is limited and not critical.

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

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

The schema already provides 100% coverage for the platform parameter, listing the allowed platform names. The description does not add additional parameter semantics or examples, so it stays at the baseline while the schema carries the weight.

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

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

The description states a clear verb and resource: retrieving account details for a specific platform, and further specifies the exact return fields (username and ID). It is distinct enough from sibling tools like accounts_list or accounts_get_follower_stats by emphasizing the first matching account, though it doesn't explicitly name a sibling for 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?

The description implies when to use the tool: when you need details for an account tied to a specific platform. It does not explicitly state when not to use it or name alternative tools that would be better for listing all accounts or retrieving health metrics.

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

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

The description adds no behavioral detail beyond what readOnlyHint=true and destructiveHint=false already declare. It does not explain what 'health' means, what is checked, or what output to expect from the agent's perspective.

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

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

The description is short to the point it is under-specified rather than concise. 'Check account health' repeats the title and does not earn its place by adding useful 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 single-parameter tool with a read-only annotation and output schema, the description should at minimum clarify that it targets one account versus all accounts. The sibling accounts_get_all_accounts_health exists, and this description does not resolve the ambiguity.

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

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

Schema description coverage is 100%, and account_id is documented as 'The account ID to check'. The description itself adds no parameter context, but the schema already carries the semantic load, 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?

Tautological: description restates name/title.

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 accounts_get_all_accounts_health or accounts_get. No alternatives, exclusions, or selection criteria are mentioned.

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 provide readOnlyHint=true and destructiveHint=false, and 'check' correctly aligns with that. However, the description discloses no additional behavioral context, such as what 'health' means, whether results are aggregated, or performance implications.

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

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

One short sentence is on its face concise, but it merely repeats the already-provided title and does not earn its place. It reads as under-specification rather than efficient communication.

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

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

The schema and annotations provide solid fallback context, and the output schema exists. Still, the description alone does not make clear that this operation covers all accounts nor how it differs from the singular-account health tool, so the surrounding context is only minimally sufficient.

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

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

The input schema has 100% parameter description coverage for status, platform, and profile_id. The description itself adds no further parameter semantics, so the baseline score of 3 applies.

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

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

Tautological: description restates name/title.

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 the closely related accounts_get_account_health or accounts_list. No context, conditions, or alternative names are provided.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds no behavioral context beyond a read-only fetch. It does not mention how the stats are computed, whether the date range is inclusive, whether granularity affects defaults, or any other behavior that is not already obvious from the schema.

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

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

The description is extremely short, but this is under-specification rather than valuable conciseness. The single sentence repeats the tool's title without adding content, so it does not earn its place in a helpful tool description.

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

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

Even though the input schema is well-documented and an output schema exists, the description itself fails to communicate what follower stats measure, how they relate to accounts and profiles, or how the tool differs from sibling analytics tools. An agent relying on this description would not know the intent or boundaries of the tool without additional inference.

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 parameters are already well-documented with their defaults and meanings. The description contributes no extra parameter semantics, but the schema handles the burden fully.

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?

Tautological: description restates name/title.

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

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

There is no guidance about when this tool should be used versus alternative analytics or account tools. It also does not mention whether the user must have an account, which account IDs are applicable, or what conditions would make a different sibling tool more appropriate.

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

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

The readOnlyHint and destructiveHint annotations already cover the safety profile, so the description doesn't need to repeat that. It does add that all accounts are returned rather than one, and identifies the resolution of output fields, but no deeper behavior like pagination or rate limits is discussed. This is acceptable given the zero-parameter and output schema 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?

Every sentence earns its place: the first states the operation, the second describes the return contents, and the third gives the primary use case. No filler, front-loaded, and appropriately short.

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 zero-parameter schema, output schema, and clear read-only annotations, this description is complete. It answers what, when, and why to call it, and connects to a real downstream need (creating posts) which helps agents compose workflows.

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

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

There are no parameters, so the description has no burden to explain parameter semantics. The 100% schema coverage and empty properties are self-evident; baseline 4 is appropriate.

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

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

The description clearly states that the tool lists all connected social media accounts, naming the exact resource and scope. It also specifies the fields returned (platform, username, account ID), which differentiates it from account-level sibling tools like accounts_get, accounts_get_follower_stats, and health checks.

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

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

The description gives a concrete use case: 'Use this to find account IDs needed for creating posts.' This is clear guidance for when to apply the tool, though it doesn't explicitly state when not to use it or name alternatives.

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

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

The annotations already declare destructiveHint=true and readOnlyHint=false, so the description does not contradict them, but it also adds no behavior beyond the word 'move'. It never explains what happens to the original profile association, whether the operation is reversible, or what side effects occur.

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

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

The description is one short, front-loaded sentence with no filler, repetition, or extra clauses. Every word is necessary to convey the basic action, even though that action is minimal.

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

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

Despite having annotations and a two-parameter schema, the description leaves the semantics of 'move' entirely to inference. It does not explain the effect on the account's original profile, any permission needs, or whether data is transferred, which is significant for a destructive operation. The presence of an output schema is not enough to compensate for this missing explanatory 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%, and the profile_id parameter includes a meaningful constraint about valid ObjectId and same-user ownership. The description itself contributes nothing to parameter understanding, so the baseline score of 3 is appropriate.

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

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

Tautological: description restates name/title.

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

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

There is no guidance about when to use this tool versus siblings like accounts_get, profiles_update, or accounts_list. The description neither states when not to use it nor identifies alternatives or prerequisites.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds no behavioral context beyond those structured hints. It does not contradict the annotations, but it also provides no additional information about pagination implications, data scope, or any side effects.

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

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

The description is technically short but is under-specified: three words that restate the title and provide no useful structural information. This is not effective conciseness but a failure to provide any added 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?

The rich input schema and annotations cover a lot of operational details, and the existence of an output schema helps, so the definition is minimally viable for invoking the tool. However, the description itself is too thin to clarify the analytical scope relative to four sibling analytics tools, and leaves the agent to infer the endpoint's true semantics from parameter names.

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

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

Schema description coverage is 100%, and each parameter has meaningful descriptions with defaults, formats, and filter semantics (e.g., date bounds, source, post_id resolution). The tool description itself adds no parameter-level meaning, so the baseline of 3 is appropriate since the schema carries the full semantic load.

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?

Tautological: description restates name/title.

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

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

No guidance is given about when to call this tool versus the other analytics tools. There are no mention of alternatives, exclusions, or conditions that would help an agent choose analytics_get_analytics over analytics_get_daily_metrics or analytics_get_post_timeline.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds no behavioral details beyond what the annotations provide, such as how 'best times' are computed, what data range is considered, or that filters are combined.

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 only a single sentence and front-loaded, but it merely repeats the title and provides no additional structure or scoping. Its brevity is not informative conciseness; it omits the context the agent needs.

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

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

Although the schema and output schema are present, the definition lacks usage context and behavioral expectations for a tool with four optional filters. An agent cannot tell what the returned 'best times' represent, their time range, or how filters affect the result.

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%: source, platform, account_id, and profile_id are each documented in the schema. The description adds no parameter-level guidance, which is acceptable given the schema carries the full 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?

Tautological: description restates name/title.

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 rather than analytics_get_analytics, analytics_get_daily_metrics, or other reporting tools. The description does not state prerequisites, default scope, or exclusions, leaving selection to inference 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 provide readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context by explaining the two attribution strategies ('publish' vs 'received') and date defaults (180 days ago to now), which affect query results. It does not discuss auth, rate limits, or pagination, but the output schema covers return structure.

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

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

The description is front-loaded with the purpose and uses a tight bulleted Args list; each parameter description adds information and the longer attribution explanation is necessary for correct use. No fluff or repetition 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 read-only analytics tool with 7 optional parameters and an output schema, the description covers all inputs, defaults, and the key behavioral distinction (attribution). Because an output schema exists, not detailing return fields is acceptable.

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

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

Schema description coverage is 0%, but the Args block documents all seven parameters with semantics: platform/profile/account filtering, inclusive ISO 8601 dates with defaults, source categorization, and a detailed explanation of attribution behavior. This fully compensates for the schema's lack of descriptions.

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

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

The description states a specific verb+resource: 'Get daily aggregated metrics,' with an Args section that further defines the scope via platform/profile/account/date filters and attribution modes. This distinguishes it from analytics siblings like analytics_get_best_time_to_post and analytics_get_post_timeline, which target different analytics slices.

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 context is clear: use this tool when daily aggregated, filterable metrics with publish- or received-based attribution are needed, and optional filters/defaults make invocation behavior predictable. It does not explicitly name alternative tools or state when not to use it, so it falls just short of 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 communicate read-only and non-destructive behavior, lowering the burden on the description. The description adds useful details like supported post ID formats and default date range, but it does not disclose any other behavioral traits such as error behavior, timezone handling, or metric aggregation semantics.

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

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

The description is compact and front-loads the tool's purpose, but the opening line repeats the title verbatim rather than adding new information. After that, it efficiently covers parameters and defaults 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 read-only post-timeline endpoint, the description provides all critical parameters and defaults needed to invoke it. The output schema likely documents the response shape, so lack of return-value detail is acceptable. It is not quite complete because it does not contextualize the result granularity or clarify how this timeline differs from sibling analytics tools.

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

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

Even though schema description coverage is 0%, the description fully compensates by explaining all three parameters. It clearly states that post_id accepts three ID formats, that from_date and to_date use ISO 8601, and what those dates default to.

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

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

The description clearly states it gets a post analytics timeline, which identifies the resource and action. However, it does not differentiate itself from sibling analytics tools like analytics_get_daily_metrics or analytics_get_best_time_to_post, so it lands below a top score.

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

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

The description provides no guidance on when to choose this tool over sibling analytics tools. It does not mention any alternatives, exclusions, or preferred contexts. While it explains date range defaults, that is parameter-level information, not usage guidance.

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

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

The annotations already convey the important safety signal with destructiveHint=true, so the description does not need to restate it. The description adds context about search_tools provenance but does not explain that the effects and output depend on the named tool, leaving much of the behavioral burden on annotations.

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

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

The description is two short sentences with the main action front-loaded. It is concise, relevant, and contains no filler.

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

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

For a generic dispatcher with a low-complexity schema and strong annotations, the description is nearly complete: it indicates what to call, what to pass, and how candidates are discovered. A minor gap is that it does not explicitly state that the result or side effects depend entirely on the selected target 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%, so the description repeats what is already in the schema. It adds no guidance about how to construct the arguments object or where the allowed names come from, but the baseline is adequate because the schema already documents both parameters.

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 action: 'Call a tool by name with the given arguments.' It also explicitly connects the tool to search_tools, distinguishing the invocation step from the discovery step.

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

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

It clearly says to use this tool for executing tools discovered via search_tools. It does not name when-not conditions or explicit alternatives beyond the implicit search_tools relationship, so it stops just short of full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description merely repeats the read-only 'Get' action without adding behavioral context such as pagination behavior, platform-specific comment ID handling, or reply expansion. There is no contradiction, but the description adds no transparency beyond the annotations.

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

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

The description is extremely short and front-loaded with no filler words. It is concise to the point of under-specification, but that brevity is not due to wasted sentences; the missing substance is better 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?

The input schema, annotations, and output schema cover a lot of the mechanical detail, including platform-specific behavior and pagination. However, the description itself lacks explicit scope and does not communicate how this tool differs from sibling comment tools, leaving selection-critical context to be inferred.

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

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

Schema description coverage is 100%, with detailed explanations for cursor, post_id, subreddit, and comment_id. The description contributes no parameter-level meaning, so the baseline score of 3 applies.

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

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

Tautological: description restates name/title.

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

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

The description provides no guidance on when to use this tool versus alternatives such as comments_list_inbox_comments or comments_reply_to_inbox_post. The only context comes indirectly from required parameters like post_id and account_id, which is insufficient for reliable selection among related comment tools.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: no mention of pagination via cursor, sort defaults, result volume, or how the inbox/filtering behaves — leaving the lower bar unmet.

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 verbose, but it is not concise in a useful sense — it is under-specified, consisting entirely of a title echo with no additional content. Brevity here reflects missing information rather than efficiency.

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

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

For a 9-parameter listing tool with no required parameters and an output schema (so return values need not be explained), the description still needs to establish filtering/sorting intent and its relationship to the sibling comment tools. None of that is present, leaving the definition inadequate for correct tool selection.

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

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

Schema description coverage is 78%, with 'limit' and 'cursor' carrying no inline description at all, and the description provides zero parameter explanation. It does not compensate for the notable gaps in the schema, so it falls below the baseline-3 case for near-complete 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?

Tautological: description restates name/title.

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 list endpoint versus comments_get_inbox_post_comments (which fetches comments on a single post) or any other sibling. There is no mention of prerequisites, pagination expectations, or exclusions.

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

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

The annotations already convey that this is not read-only, likely has open-world effects, and is marked destructive, so the description is not the sole signal. However, the description adds no context beyond annotations—it does not explain what side effects replying to a comment has or why the destructive hint is set.

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

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

The description is short, but it is under-specified rather than genuinely concise. It spends its single sentence saying exactly what the tool name and title already say, adding no structural or scoped information.

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

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

Given that the tool has 8 parameters, platform-specific details, and a rich schema, the description should orient the agent to when and why this tool is the right one. The schema covers the parameter details, but the description's failure to provide any kind of behavioral context leaves the overall definition incomplete for an agent.

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 each of the 8 parameters is already individually documented in the input schema. The description adds no further parameter-level meaning, but the schema does the necessary work, keeping this at the baseline.

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

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

Tautological: description restates name/title.

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 explanation of when to use this tool versus alternative comment or reply tools. The intended usage is only implied by the tool name and title, with no mention of exclusions, prerequisites, or alternative choices.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral value beyond annotations by disclosing what results look like: 'contextual content with section titles and relevant snippets.' This helps set expectations about return structure without contradicting the annotations.

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

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

Three sentences with no filler: the first states the operation, the second gives when to use it, the third describes the output format. It is front-loaded and each 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 the single-parameter schema, full schema coverage, and an output schema present, the description provides all necessary context for a search tool. The return behavior is described, safety is covered by annotations, and nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, including an example query ('webhooks', 'create post', 'authentication'), so the description need not elaborate further. The description adds no parameter-level detail, but the schema already fully documents the single query 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 states a specific verb and resource: 'Search across the Late API documentation.' It also enumerates the content types (code examples, API references, guides), and the named resource 'Late API documentation' distinguishes it from siblings like search_tools, which searches tools.

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

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

The description gives explicit when-to-use guidance: answer questions about Late, find specific documentation, understand features, or locate implementation details. It does not explicitly contrast with alternatives like search_tools, but the condition is clear enough for an agent to route to this tool.

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

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

Annotations already mark the operation as read-only and non-destructive. The description adds meaningful behavioral context by enumerating the possible statuses (pending, completed, expired) and indicating that file URLs are returned once complete.

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 only a few sentences long, front-loads the core purpose, and then provides actionable usage and return-value context without unnecessary detail. Every sentence contributes.

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

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

The tool is simple, has only one required parameter, benefits from an output schema, and carries read-only annotations. The description adds the missing workflow context and status semantics, making it complete for an agent 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?

The token parameter is already fully described in the schema, including its source. The description restates that a token is involved but adds no new structural or format details, so the schema carries the parameter documentation weight.

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: checking the status of an upload token and retrieving file URLs. It clearly describes the tool's outcome and differentiates it from the related generation flow by mentioning the browser upload stage.

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

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

The description explicitly tells when to use the tool: after the user has uploaded files through the browser upload page. It does not name alternatives or state when not to use it, but the usage context is clear enough for an agent to select it appropriately.

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

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

The description adds important behavioral context beyond the annotations: the tool does not upload files itself, the user must open the browser URL, and a subsequent status-check call is needed to get the real uploaded file URLs. It does not expand on what the destructiveHint annotation might be protecting against, but it at least provides a full interactive flow.

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

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

The description is efficient: a single defining sentence followed by a compact numbered flow. Every sentence earns its place, and the most important purpose ('generate an upload URL') is front-loaded.

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

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

For a zero-parameter tool with an output schema, the description covers everything an agent needs: the trigger condition, the full upload workflow, the next tool to call, and how the finished URLs fit into post creation. Nothing important for executing the tool correctly is missing.

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

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

The input schema is empty, so with zero parameters there is almost no semantic burden on the description. The description correctly avoids claiming any inputs, and the schema itself already provides unambiguous parameter information.

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

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

The description clearly states the action: generate a unique upload URL for media files. It also gives the exact purpose—letting a user upload files via browser before creating a post—so an agent can distinguish this tool from related media and publishing tools.

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

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

The description says 'Use this when the user wants to include images or videos in their post' and provides a numbered flow that explains when to call the tool and what the next steps are. No alternatives are needed here because the workflow is explicit and the progression to media_check_upload_status and posts_create is described.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the tool's safety profile is clear and the description does not contradict it. However, the description adds no behavioral context beyond the bare 'List' action, so it does not reach a higher score.

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

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

The description is short, but it is under-specified rather than concisely informative. The single sentence simply repeats the title and does not earn its place by adding scope, context, or alternative guidance.

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 optional filter and pagination parameters and a large sibling set, the description is incomplete. It omits the 'inbox' scope, the relationship to mentions_reply_to_mention, and the available filters; the output schema covers the return shape, but not the conceptual context needed to select this tool correctly.

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

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

Schema description coverage is 80%, with cursor, account_id, profile_id, and sort_order documented in the schema. The description itself contributes no parameter detail, but because structured coverage is high, the baseline of 3 applies; the only undocumented parameter is limit, whose default of 25 is self-explanatory.

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?

Tautological: description restates name/title.

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

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

The description contains no guidance about when to use this tool or which alternatives exist. An agent must infer entirely from the tool name that this is the inbox-mention listing operation, with no explicit context or exclusions.

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

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

Annotations already carry the safety profile (readOnlyHint=false, destructiveHint=true, openWorldHint=true), and the description adds no behavioral context beyond restating the action. It does not disclose that the reply is posted publicly and immediately, that it cannot be retracted, or what side effects the destructive flag implies. The description does not contradict the annotations, but it contributes nothing to behavioral 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?

At four words, the description is brief, but this is under-specification rather than effective conciseness — there is no substantive content to front-load or structure. No sentence earns its place because the single sentence merely repeats the title.

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

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

The structured data is rich (100% parameter coverage, output schema present, annotations present), which lowers the burden on the description. However, the description omits the critical two-mode behavior (replying to a comment mention vs a caption mention) and fails to differentiate from sibling reply tools, leaving the agent to infer essential usage details from the schema alone.

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

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

Schema description coverage is 100%, so the baseline of 3 applies; every parameter (account_id, media_id, message, comment_id) already has a meaningful description in the schema, including the 'Omit for a caption mention' nuance. The description itself says nothing about parameters, so it neither helps nor hurts — the schema carries the full 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?

Tautological: description restates name/title.

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 guidance on when to use this tool versus comments_reply_to_inbox_post, nor does it mention the typical workflow of discovering mentions first via mentions_list_inbox_mentions. The only usage nuance (omit comment_id for a caption mention) appears in the schema rather than the description, leaving the agent without any 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?

The annotations already mark readOnlyHint false and destructiveHint true, so the agent knows this is mutating, but the description adds no context about what the destructive behavior is or what side effects occur. The only behavioral clue is the 'dry_run' argument name, but the description never explains that dry_run might prevent actual changes.

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 very short, but this is under-specification rather than valuable conciseness. 'Args: dry_run' looks like a placeholder and does not provide meaningful content that helps an agent call the tool correctly.

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 destructive annotation, the massive sibling tool list, and zero parameter schema coverage, the description is severely incomplete. Missing critical information includes how the CSV is supplied, what dry_run actually controls, which post fields are expected, and whether bulk upload is additive or can replace/delete existing posts.

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 merely repeats the parameter name 'dry_run' without explaining what it controls or how it should be used. A parameter named dry_run is far from self-explanatory, and the description must 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?

The description, 'Bulk upload from CSV', exactly matches the tool's title and name, so it is almost a pure tautology rather than a substantive explanation. It identifies a verb and resource, but an agent gets no detail about whether this creates new posts, replaces existing ones, or imports into a queue.

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

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

No guidance is given about when to use bulk upload versus sibling tools like posts_create or posts_cross_post. The description does not state prerequisites, scenarios, or exclusions, so the agent cannot decide between this tool and alternatives based on the description 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?

The description adds real behavioral context beyond annotations: draft posts are saved but not published/scheduled, immediate mode goes live right away, scheduled mode publishes later, and omitted account_id triggers a recoverable error listing candidates. This is strong transparency and does not contradict the annotations.

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

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

The structure is exemplary: a short top-level summary, mode-specific headers, bolded parameter names, explicit Spanish/English usage phrases, and examples with minimal redundancy. It is long, but every block earns its place by resolving a high-stakes ambiguity for a 9-parameter 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?

Given the complexity of 9 parameters, a multi-account pitfall, and schema coverage, this description gives enough to avoid the most common failures: mode confusion, missing account_id, and scheduling semantics. It covers recovery from error, and the output schema exists, so the description does not need to explain return values.

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

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

All parameters are already documented in the schema, so the baseline is 3. The description adds extra value by explaining the interplay between is_draft, publish_now, schedule_minutes, account_id, and profile_id via concrete user phrases and examples, therefore lifting it above baseline.

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

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

The title and description clearly state the tool creates a social media post and identifies the three possible states (draft, scheduled, immediate). This distinctively differentiates it from sibling tools like posts_publish_now, posts_edit_post, and posts_list by emphasizing the create-and-mode-selection behavior.

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

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

The tool gives explicit, thoughtful usage guidance by tying specific user phrases to each mode and requiring account_id discovery via accounts_list for multi-account users. It lacks an explicit 'not this tool' statement for neighboring create-related siblings like posts_cross_post or posts_publish_now, so it is clear but not fully exclusionary.

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

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

Beyond destructiveHint=true, it explains that drafts stay unpublished, immediate posts go live on all platforms, the default schedule is one hour out, and multi-account resolution can fail with a candidate list. It does not explicitly state irreversibility or rate limits, but annotations already cover the destructive nature.

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

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

The description is well-structured with scannable mode blocks and multi-account bullets, and the purpose is front-loaded. It is somewhat long, but most sentences carry necessary selection or retry behavior.

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 7-parameter cross-posting tool, the description is largely complete: required params are clear, mode behavior is specified, and multi-account errors are explained. The main caveat is that SCHEDULED MODE says 'in X hours' but actually schedules for 1 hour from now, which can mislead an agent.

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

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

Schema coverage is 100%, and the description adds real meaning by tying is_draft and publish_now to mode selection and by explaining account_ids parallel ordering, empty-string fallback, and repeated platform names. It does not address conflicts like both is_draft and publish_now being true, which is a minor 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 opening sentence states a concrete action and scope: 'Post the same content to multiple platforms at once.' This clearly distinguishes the tool from single-platform siblings like posts_create and posts_publish_now.

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

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

The description gives explicit intent-based triggers for draft, immediate, and scheduled modes, including user phrases and default behavior. It stops short of a 5 because it does not explicitly name sibling alternatives or state when not to use cross-posting.

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

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

Annotations already signal that this is destructive and not read-only; the description adds a useful guardrail by stating that published posts cannot be deleted. It doesn't describe side effects, soft-delete behavior, or error handling, but the annotation plus limitation is enough for a modest score.

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

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

The description is only two sentences, with no filler. The main action is front-loaded, and the crucial constraint about published posts immediately follows.

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

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

For a single-parameter destructive operation with an output schema present, the description covers the what, the required parameter, and the primary state restriction. No extra information about return values is necessary because the output schema exists, and the destructive behavior is already annotated.

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

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

Input schema coverage is 100%, and the schema already describes post_id as 'The post ID to delete (required).' The description's usage of 'by ID' adds no new semantics, so it rests at baseline 3.

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

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

The description clearly states the tool's action ('delete a post') and the ID-based targeting, which is specific enough to distinguish from post-creation, listing, and editing tools. However, it does not explicitly contrast with the related sibling posts_unpublish_post, so the differentiation is not maximally explicit.

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

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

The description conveys an important limitation: 'Published posts cannot be deleted,' which implicitly tells an agent when not to use this tool. It does not identify alternative workflows or sibling tools (e.g., unpublishing first), so usage guidance remains implied rather than 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 signal destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context of its own. It does not mention immediate effects on the published post, whether the change is reversible, or any platform/account consequences.

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

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

The description is extremely brief, but brevity here is under-specification rather than effective conciseness. It adds no structure or useful framing beyond the tool title.

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 large sibling toolset for posts, the description is too sparse to help an agent select this tool over posts_update, posts_delete, or posts_publish_now. The schema and annotations support invocation but the description's lack of context leaves the tool's place in the workflow ambiguous.

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 carries the parameter details and the description does not need to repeat them. The description itself contributes no parameter-level meaning, but the baseline 3 applies because properties like account_id are already documented reasonably well.

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

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

Tautological: description restates name/title.

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 context is given. The description does not say to use this for editing already-published posts versus drafts or scheduled posts, and does not mention alternatives such as posts_update or posts_publish_now.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety behavior is covered. The description adds useful context about what is returned (content, status, scheduling info), but it does not disclose operational details such as pagination, authorization, or error behavior.

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

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

The description is a single, front-loaded sentence with a clear verb, object, and scope. Every word carries meaning; there is no repetition of the tool name or generic 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?

This is a simple, read-only getter with one required parameter and an output schema. Together, the description and schema provide enough for an agent to know what the tool does, what input is required, and what to expect, without extra prose.

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

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

The input schema has 100% description coverage: post_id is already documented as the ID to retrieve and is marked required. The description adds no extra parameter-level information beyond what the schema provides.

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

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

The description uses a specific verb ('Get'), a clearly scoped resource ('a specific post'), and specific details (content, status, scheduling info). It distinguishes from posts_list by emphasizing 'specific post', though it does not explicitly name sibling tools.

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

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

The description implies the use case (retrieving full details for a single post, including status/scheduling info), but it does not explicitly state when to prefer this tool over alternatives like posts_list or when not to use it. No alternative tools are mentioned.

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 carry readOnlyHint and destructiveHint safety, so the read-only behavior is known. The description adds little beyond that—there is no mention of ordering, pagination, or how the list is scoped, but it does not contradict the annotations.

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

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

The description is short, front-loaded with the purpose, and lists status options in an easy-to-scan line. It wastes little space, though the first sentence is largely a restatement of the tool title.

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 two fully documented parameters, an output schema, and clear annotations, the description is almost complete enough. The remaining gap is mainly the sibling choice between posts_list and posts_list_failed, which belongs more to usage routing than basic 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 100%, so both limit and status are already fully documented with defaults and value options. The description only repeats the status values from the schema without adding deeper meaning, so it stays at the high-coverage baseline.

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

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

The description clearly states the verb and resource: 'List posts' with optional filtering by status. It gives enough scope to distinguish from post creation, retrieval, and deletion siblings, though it does not explicitly disambiguate from the near name posts_list_failed.

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

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

The intended use is implied: browse posts, optionally narrowed by status, with clear status options listed. However, the description never says when not to use it or which sibling alternative to choose, especially since posts_list_failed also exists and overlaps with the failed status.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is covered. The description adds the meaningful 'retry-eligible failed posts' filter, but does not discuss pagination or how 'failed' is defined.

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 short sentence with no filler. It front-loads the action and includes essential scoping information ('failed posts' and 'that can be retried') 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?

For a read-only list tool with zero required parameters, a documented limit, and an output schema present, this description is sufficient for correct invocation. It does not explain failure status scope or pagination behavior, but those are minor given the tool's simplicity.

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 only parameter, limit, is already fully documented in the schema with its default value. The description adds no additional meaning about the limit parameter, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb ('List') and resource ('failed posts'), and adds the eligibility qualifier 'that can be retried.' This distinguishes it clearly from broader tools like posts_list and from retry actions like posts_retry or posts_retry_all_failed.

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 'that can be retried' gives useful context about what subset is returned, implying it is useful for inspecting retry candidates. However, it provides no explicit guidance about when to prefer this tool over other list/retry sibling tools.

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

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

Annotations only indicate readHint=false and destructiveHint=true. The description adds that the post 'goes live right away', identifies the wrapper relationship to posts_update, and warns about multi-account behavior with a clear list lookup step. It doesn't fully discuss reversibility or failure handling, but the destructive annotation covers the core risk.

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 paragraphs front-load the core action, then add usage context and a warning. Every sentence earns its place, and the warning is appropriately emphasized with a bullet and icon. No unnecessary fluff.

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

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

With a full input schema, output schema, and annotations, the description adds the key missing decision criteria: when to use it, how to handle multiple accounts, and how to resolve the account via the accounts_list call. Nothing essential is omitted.

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 parameters are already documented. The description reinforces 'account_id' for multi-account scenarios, but the schema already states the same requirement; it adds little beyond what's structured.

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

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

Description clearly states a specific action: 'Publish a post immediately to a platform' and reinforces the result ('The post goes live right away'). It distinguishes itself as 'a convenience wrapper around posts_create with publish_now=True', which differentiates it from siblings like posts_create and posts_cross_post.

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 defines when to use: 'Use this when user explicitly wants an immediate post NOW, not schedule for a later time.' It also provides a clear prerequisite for multi-account users: 'pass account_id' and 'Call accounts_list first.' Alternatives are implied through the wrapper reference, and the condition is unambiguous.

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

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

The annotations already mark this as non-read-only and destructive, so the description does not need to restate those traits. It adds useful behavioral context by noting the failed-status requirement and clarifying that the tool triggers a publishing retry rather than a generic update.

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

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

The description is minimal, clear, and front-loads the core action in the first sentence. The additional sentence earns its place by stating the only-supported status, with no redundant or filler content.

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

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

Given a single required parameter, full schema coverage, an output schema, and annotations that already disclose side effects, the description is complete enough for effective use. The missing detail about all-failed retries is not essential because sibling names communicate that distinction.

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

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

The input schema already fully documents post_id with 100% description coverage. The tool description adds no additional parameter-level detail beyond what the schema provides, so a baseline score of 3 is appropriate.

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

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

The description clearly states the operation: retry publishing a failed post. It also narrows the scope to posts with 'failed' status, which distinguishes this tool from similar publishing/retry-related siblings like posts_publish_now and posts_retry_all_failed.

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

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

The description gives a clear precondition: only use this tool on posts with 'failed' status. It does not explicitly name an alternative for retrying all failed posts, but the scope is specific enough to guide basic tool selection.

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

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

Annotations already convey the non-read-only and destructive nature, and the description adds a meaningful behavioral nuance: it acts on all failed posts in a single operation. However, it does not disclose potential side effects such as re-publishing content, creating duplicate activities, or whether the retry is immediate and irreversible.

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 concise single sentence and is front-loaded with the key action. It loses one point because it mostly restates the title with only 'at once' adding new information, making it slightly redundant rather than truly additive.

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

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

Given the output schema exists and annotations cover the destructive profile, the description is minimally adequate. Still, for a zero-parameter bulk action, an agent would benefit from more context about the scope of 'all failed posts' and what a retry entails, so the description leaves meaningful gaps.

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

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

The tool has no parameters and the input schema already reflects that fully, so there is no gap to compensate for. Baseline 4 is appropriate since the description is not required to explain any parameters.

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

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

The description clearly states the action (retry) and resource (all failed posts), and 'all ... at once' semantically distinguishes it from the single-action sibling posts_retry. However, it does not explicitly name or contrast itself with that sibling, so the differentiation is implied rather than explicit.

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

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

The description provides no guidance on when to use this tool versus alternatives like posts_retry or posts_list_failed. The intended context is only implied by the wording 'all failed posts,' and no exclusions or preconditions are mentioned.

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

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

The description does not disclose behavioral context beyond the annotations. The destructiveHint annotation already signals mutation/deletion risk, and the description merely repeats 'Unpublish post' without explaining side effects, reversibility, permission needs, or impact on the post.

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 very short, but this reads as under-specification rather than effective conciseness. A useful description would briefly explain the unpublish action and its scope while remaining succinct.

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 this is a destructive, platform-scoped tool with meaningful sibling tools, the description is not complete enough. It does not clarify what 'unpublish' does, contrast with related posts tools, or explain what happens to the post.

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

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

The input schema has 100% description coverage, so the schema carries most of the parameter meaning. However, post_id is only described as '(required)', and the tool description adds no further semantic value to either 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?

Tautological: description restates name/title.

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

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

No guidance is given about when to use this tool versus siblings like posts_delete, posts_publish_now, or posts_retry. The agent is left to infer use cases and exclusions entirely from the tool name and parameter hints.

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 set readOnlyHint=false and destructiveHint=true, so the mutation nature is attested. The description adds the status restriction, which is useful behavioral context, but it does not describe side effects such as overwriting fields or whether updates are partial.

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

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

The description is compact and front-loaded: the first sentence names the action, and the following sentences sharpen the intended use. Every sentence earns its place without filler or repetition.

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

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

For a four-parameter tool with a required post_id, full schema coverage, an output schema, and annotations, the description covers core behavior and usage restrictions. It is slightly incomplete because it does not clarify how `posts_update` differs from the sibling `posts_edit_post`.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds no parameter-level meaning beyond what the input schema provides, so the 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?

Description clearly states the verb 'Update' and the resource 'an existing post', and the status restrictions add scope. It does not adequately distinguish itself from the sibling tool `posts_edit_post`, since both appear to target existing posts.

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

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

The description explicitly says draft, scheduled, and failed posts can be updated and that published posts cannot. This gives clear when-to-use and when-not-to-use context, though it does not explicitly name alternative tools or workflows for published posts.

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

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

Annotations already signal the mutation/destructive behavior (readOnlyHint=false, destructiveHint=true), so the description does not need to repeat that. It adds the contextual detail 'for grouping social accounts' but does not disclose any further side effects, prerequisites, or failure modes.

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

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

The description is one concise, front-loaded sentence. It clearly states the action and purpose with 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?

The tool is straightforward, the schema documents all parameters, and an output schema exists. The description plus schema provide enough information for an agent to create a profile correctly, though a bit more detail about naming rules or side effects would push it higher.

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 parameters are fully documented in the schema itself. The description adds no additional parameter semantics beyond naming the purpose, which is acceptable given the baseline of 3 for complete schema coverage.

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

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

The description names a specific verb ('create') and resource ('profile'), and explains the purpose ('grouping social accounts'). This clearly distinguishes it from sibling operations like profiles_update, profiles_delete, and profiles_list.

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

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

The description implies when to use the tool (when creating a new profile), but it does not explicitly state when not to use it or mention alternative tools such as profiles_update for modifying existing profiles. Some guidance is left to inference from sibling names.

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 provide destructiveHint=true and readOnlyHint=false, so the description is not required to repeat that behavior. The description adds the precondition about connected accounts, which is useful, but it does not disclose what happens if the precondition is violated or whether the deletion is permanent. The behavior is adequately covered by the annotations.

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

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

The description is two short sentences with no unnecessary words. The core action is front-loaded, and the precondition is presented cleanly. Every sentence contributes meaningful information.

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

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

For a simple delete operation with one parameter, an output schema, and strong annotations, the description is complete enough. It states the critical precondition, which is the main contextual risk. A slightly fuller note on consequences of the preconditions would be ideal, but the current level is sufficient.

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

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

The schema has full description coverage for the single profile_id parameter, including a handy statement that it is required. The description does not add extra meaning beyond the schema, so the baseline score of 3 is used.

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

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

The description clearly states the action as 'Delete a profile', specifying both the resource and the operation. It distinguishes itself from sibling tools like profiles_get and profiles_update by explicitly identifying the deletion lifecycle action. The added precondition about connected accounts further sharpens the purpose.

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

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

The only usage guidance is the precondition 'The profile must have no connected accounts', which implicitly tells the agent when deletion is valid. However, it does not explicitly name alternative tools or describe when not to use this tool beyond the precondition. This is clear 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 destructiveHint=false, and the description's 'Get details' is consistent with that. The description adds minor context by naming returned fields, but does not disclose additional behavior such as permissions, results, error cases, or pagination.

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

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

The description is one concise sentence that states the purpose and a few representative fields. It is front-loaded and there is no significant waste, though it is close to the title in wording.

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

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

For a simple single-parameter get tool with readOnlyHint=true, destructiveHint=false, and an output schema present, the description is sufficient for invocation. It could add more sibling-comparison guidance, but none is strictly necessary for correct use.

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

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

The input schema covers the single profile_id parameter 100% and marks it required, so the schema carries the parameter documentation burden. The description adds little beyond implying that the target is a profile, which is appropriate given coverage.

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

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

The description clearly states a specific verb ('Get') and resource ('details of a specific profile') and lists example fields. It is easy to distinguish from profiles_list, profiles_create, and profiles_update because it focuses on retrieving a single profile, though it does not explicitly call out a sibling.

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

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

The description implies the use case: retrieve details of one profile. However, it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention an alternative like profiles_list for enumerating profiles.

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

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

The description is consistent with the readOnlyHint and destructiveHint annotations, and adds the conceptual detail that profiles group social accounts. It does not describe pagination, ordering, or response shape, but for a read-only list tool the annotations carry much of the burden.

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

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

The description is short and front-loaded with the core behavior. The second sentence provides helpful domain context without adding unnecessary length, though it is not strictly required to invoke the 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 parameterless, read-only list tool with an output schema, the description is sufficient for selecting and invoking the tool. The only missing contextual detail is possible behavior such as pagination or ordering, which is not essential 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?

The tool has zero parameters, so there is no parameter-usage burden for the description to carry. The empty schema is consistent with the stated behavior of listing all profiles without filters.

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

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

The description clearly states the verb and resource: 'List all profiles.' The second sentence adds useful conceptual context by explaining that profiles group multiple social accounts together. It does not explicitly differentiate from sibling tools like profiles_get or account_groups_list_account_groups, but the intent is unambiguous.

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

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

The use case is implied: an agent needing the full set of profiles should call this tool. However, there is no explicit guidance about when to prefer this over similar list tools such as accounts_list or account_groups_list_account_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?

The phrase 'Only provided fields will be changed.' adds important partial-update semantics that the annotations (destructiveHint) do not convey. It clearly communicates that omitted fields are preserved, which is valuable for correct invocation, though it does not detail other side effects such as validation behavior.

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

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

The description is two short sentences with no fluff or repetition. The key semantic rule is stated in the second sentence, making the description easy to skim while still being informative.

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 a defined output schema and 100% schema parameter coverage, the description is sufficient for an agent to invoke it correctly. It covers the crucial partial-update behavior and clarifies scoped the invocation; a missing guidance on profile lifecycle context is minor.

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 adds a cross-parameter rule: only provided fields are changed. This clarifies that omitted parameters are not reset, which is especially useful for fields like is_default with a schema default of false. This goes beyond the per-field schema notes.

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

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

The description uses a precise verb-resource pair, 'Update an existing profile', making the operation unambiguous. It also differentiates itself from siblings like profiles_create, profiles_delete, and profiles_get by using the word 'existing' and the update 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 word 'existing' implies the profile must already be there, but there is no explicit guidance about when to choose this over profiles_create or when not to use it. The context of updating is clear, but no alternatives or exclusions are provided.

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

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

Annotations already show destructiveHint=true and readOnlyHint=false, so the agent knows this is a mutating operation. The description adds no additional behavioral context—nothing about side effects, idempotency, required permissions, or what the mutation does to existing schedules. It does not contradict the annotations, but it also does not go beyond them.

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

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

One short sentence is concise, but it is under-specified to the point of being tautological. It has no useful content beyond repeating the tool title, so the sentence does not actually earn its place in the definition.

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 create operation with 5 parameters, an output schema, and many sibling queue tools, this description is completely inadequate. It omits what name, timezone, profile_id, and slots are used for, how they relate, and what effect creating a queue slot has. The annotations tip off destructiveness, but the description leaves the agent unable to build a 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 80% (4 of 5 params have descriptions), so the schema itself provides most of the meaning. The description adds no parameter detail, but with high schema coverage the baseline of 3 is appropriate. The 'slots' parameter is only marked '(required)', so some ambiguity remains, but the tool description could have compensated for that gap 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?

Tautological: description restates name/title.

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 context is provided about when to use this tool versus alternatives such as queue_update_queue_slot or queue_list_queue_slots. The description implies a creation action, but gives no prerequisites, no conditions, and no guidance on choosing this over 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?

The annotations already communicate destructiveHint=true and readOnlyHint=false, so the description adds no new behavioral information. It fails to disclose the scope of destruction, particularly that an omitted queue_id results in deleting all queues for the profile. With no extra behavioral context beyond what annotations provide, this is a minimal score.

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

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

'Delete schedule' is not merely concise; it is under-specified. It provides no usable structure or front-loaded decision cues. A two-word phrase that repeats the title is closer to missing content than to effective 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, the description fails to convey the resource being affected (queue slot, schedule, or all queues) or the implications of optional queue_id. Although the output schema exists, the description leaves critical operational semantics to the agent to infer from the name and 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?

The input schema provides full documentation for both parameters, including the critical rule that omitting queue_id deletes all queues for the profile. With 100% schema description coverage, the description does not need to add parameter details, meeting the baseline.

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

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

Tautological: description restates name/title.

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

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

No guidance is given about when to select this tool over alternatives such as queue_update_queue_slot or queue_list_queue_slots. There is no mention of the critical behavior that omitting queue_id deletes all queues for a profile, which is essential for safe usage.

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 (readOnlyHint=true, destructiveHint=false) already disclose the safety profile, but the description adds no behavioral context on top of that — it does not say whether the slot is reserved, whether the result is stable across calls, or how it behaves when no slot exists. The description is not contradictory to the annotations, but its contribution beyond them is effectively zero.

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 five-word sentence with no wasted words, so it is appropriately short. However, this counts as under-specification rather than genuine economy — the sentence conveys no information beyond the title, so brevity is achieved by saying almost nothing.

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

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

The output schema exists, so the return shape does not need to be described, but the description omits the one thing that would make the tool actionable: what 'next available' actually means (i.e., how the slot is determined relative to the queue and current time). Neither does it clarify how this relates to profile_id vs queue_id selection, leaving agents to guess the tool's semantics even when they know how to pass the arguments.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the description text adds nothing about the parameters. queue_id is adequately described in the schema ('Specific queue ID (optional, defaults to profile's default queue)'), but the profile_id description is the tautology '(required)' — the description itself does not compensate for that weakness.

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?

Tautological: description restates name/title.

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

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

The description contains zero guidance about when to call this tool versus the five other queue_* siblings (queue_create_queue_slot, queue_delete_queue_slot, queue_list_queue_slots, queue_preview_queue, queue_update_queue_slot). It does not state when this tool is appropriate, nor does it exclude alternatives (e.g., noting it does not reserve/consume the slot).

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds no further behavioral context, such as whether 'all' returns all queues or whether queue_id scopes the result, but it doesn't contradict the annotations.

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

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

Two words is under-specification, not effective conciseness. 'List schedules' repeats the title without earning its place; a useful description should at least mention queue slot listing or the profile scope and key optional flags.

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?

Though the schema covers parameters and the output schema exists, the description is too terse to be fully self-contained. An agent has to rely on the renovation tool name and parameter docs to reconstruct intent, making this minimally viable but not complete.

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

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

The input schema provides 100% coverage on all three parameters, including the meaning of profile_id, all, and queue_id. The description adds no parameter-level information, which is acceptable given the schema-level completeness; 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?

Tautological: description restates name/title.

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

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

No guidance is given about when to use this tool versus alternatives. There is no mention of filtering by all vs queue_id, when to prefer this over queue_preview_queue, or what prerequisites exist (such as a valid profile_id). The agent is left to infer usage from the schema alone.

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

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

The annotations already indicate readOnlyHint and destructiveHint, but the description adds no behavioral context beyond the word 'preview'. It does not explain ordering, what 'upcoming' means, whether the default queue is always used, or how the count affects the result.

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

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

The description is short but not effective: it merely restates the title and provides no front-loaded distinguishing information. Under-specification should not be mistaken for 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?

Given the presence of several queue-related sibling tools, this description is too sparse to allow reliable selection and invocation. The output schema exists, but an agent still cannot tell how preview relates to list, get_next, create, or update, or what behavior to expect.

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

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

The input schema already documents queue_id and indicates defaults, and the description adds no parameter-level meaning. Since schema coverage is 67% and the count parameter lacks a real description, the tool description would need to compensate, but it 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?

Tautological: description restates name/title.

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 the many queue-related siblings. The description does not mention alternatives, prerequisites, or a scenario where previewing is preferable to listing or fetching the next slot.

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 indicate destructiveHint=true and readOnlyHint=false, but the description adds no behavioral context beyond the actions already implied by the name. It does not mention side effects, replanning behavior, or what happens to existing scheduling data when the update is applied.

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 only two words, which is short but not usefully concise. It repeats the title instead of describing behavior, parameters, or intended usage in a structured or informative way. This is under-specification rather than 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?

Despite having annotations and an output schema, the context is still incomplete for a destructive 8-parameter update operation. The description does not communicate the semantics of the schedule slot update, what the 'slots' represent, or how this relates to the queue lifecycle. An agent would need extra inference to safely and correctly use this tool.

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

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

With schema description coverage around 88%, the schema carries most of the parameter meaning, so the baseline is 3. The description itself provides no parameter guidance, but most parameters have at least minimal schema descriptions such as 'Make this queue the default' and 'Whether to reschedule existing queued posts to match new slots.'

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?

Tautological: description restates name/title.

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

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

No guidance is given about when to use this tool versus alternatives like queue_create_queue_slot, queue_delete_queue_slot, or queue_preview_queue. There are no exclusions, no scenario descriptions, and no hint about which conditions would make this tool the favored 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 readOnlyHint=true, so no safety risk is hidden. The description adds that results are 'ranked by relevance' and returned 'in the same format as list_tools,' which gives useful context beyond the annotation, but it does not describe edge cases or query limitations.

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

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

Two concise sentences deliver the action, input, and return behavior with no filler. The most important information is front-loaded.

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

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

For a one-parameter search tool with an output schema and annotations, the description is sufficiently complete. Mentioning that results match list_tools' format covers expectations, though it could have named a couple of query examples.

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 query parameter is described as a 'natural language query to search for tools.' The tool description adds no additional parameter semantics, so the schema is doing all the work. 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 clear action ('Search for tools') and resource ('tool definitions'), with natural language as the input method. It distinguishes itself from list-like tools by emphasizing 'matching' and 'ranked by relevance', though it does not explicitly name a comparable alternative.

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

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

The description implies this tool is for natural-language discovery when you need a subset of relevant tools, but it never states when to use list_tools instead or why search_tools should be preferred over simple listings. This is adequate but not 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 destructiveHint=false, so the safety profile is covered. However, the description adds no behavioral context beyond the annotations—no mention of time-bound behavior, aggregation effects, or scoping semantics. It contributes nothing extra.

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

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

The description is one short sentence, but it is uninformative and simply mirrors the title. This is under-specification rather than effective conciseness; the sentence 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?

Though the schema and output schema provide structural richness, the description does not clarify what 'aggregated event stats' actually represents, when to use this tool, nor how it relates to sibling analytics tools. The lack of descriptive context leaves the agent to guess at the tool's intent and scope.

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

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

Schema description coverage is 100%, with all 5 parameters documented including types, defaults, and required status. The description adds no additional parameter semantics, so the baseline of 3 applies.

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

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

Tautological: description restates name/title.

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 instead of the many sibling analytics and tracking tools. No exclusions, alternatives, or context are provided. An agent would have to infer usage entirely from the name and schema.

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 read-only and non-destructive behavior, and the description adds nothing beyond that. It does not disclose that `ad_account_id` is ignored for OpenAI Ads, does not mention any platform-specific behavior, and does not describe the response shape. The description does not contradict annotations.

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

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

The description is extremely short, front-loaded with the action, and contains no filler. However, this conciseness borrows heavily from the title rather than adding new 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 a complete input schema and an output schema available, the tool is technically invokable when following the structured fields. However, the description leaves out the business context of tracking tags, the relevance of the platform (`metaads` vs `openaiads`), and how this list relates to other tools, making it only minimally complete.

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

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

Schema description coverage is 100%, and the schema thoroughly explains `account_id` and `ad_account_id`, including the optional Meta-only scope. The description itself adds no parameter-level meaning, so the schema correctly carries the 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?

Tautological: description restates name/title.

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 `tracking_tags_get_tracking_tag_stats` or when the optional `ad_account_id` should be provided. The description does not mention Meta vs OpenAI Ads behavior, so an agent must infer usage entirely from parameter names.

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

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

The description goes far beyond the readOnlyHint/destructiveHint annotations by explaining reconciliation behavior, billing-period fallback, granularity effects on the days series, attribution semantics, mutual exclusions, and 404 conditions. This gives the agent concrete expectations of tool behavior without contradicting the annotations.

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

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

The content is dense and mostly necessary, with each parameter earning its place and constraints clearly front-loaded. The only minor redundancy is the opening line repeating the title verbatim; otherwise the structure is efficient for the complexity involved.

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

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

Given the tool's 8-parameter complexity and the presence of an output schema, the description covers all essential operational context: modes, date resolution, required-parameter relationships, mutual exclusions, and failure conditions. Nothing critical for correct invocation is left undocumented.

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 responsibility for explaining parameters. It does this thoroughly: every one of the 8 parameters gets meaningful detail including defaults, required conditions, allowed value semantics, and interaction with other parameters.

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

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

The description clearly frames the tool as providing a usage snapshot by default or billed-spend metering when parameters are supplied. It identifies the resource (usage) and the two behavioral modes, though it relies on the tool name for the 'get' verb and the opening line duplicates the title.

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

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

The description gives clear guidance on when to use each mode: snapshot is default, metering is enabled via group_by/profile_id/account_id, and custom ranges require from_/to. It also states mutual exclusions and required parameters, effectively telling an agent how to choose parameter combinations. It does not explicitly name sibling alternatives, but no sibling appears to offer the same usage snapshot/metering capability.

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

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

The description reads as a harmless checking operation while annotations set readOnlyHint to false and destructiveHint to true, which is an annotation contradiction. It does not disclose what destructive behavior may occur, what side effects accompany validation, or when the tool might mutate or remove data.

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

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

At three words, this is under-specification rather than effective conciseness. The description repeats the tool title exactly and offers no meaningful guidance for an agent selecting or invoking the 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?

The schema is simple and an output schema exists, but the description still lacks critical context: when to use this tool, what side effects it may have, and why the annotation labels it destructive. That ambiguity is risky for an agent invocation 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 coverage is 100%, and the schema already describes the required url parameter as 'Public media URL to validate (required)'. The description itself adds no extra meaning beyond the schema, but the baseline for full schema coverage 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?

Tautological: description restates name/title.

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 context or exclusions are provided. The description gives an agent no reason to choose this over the validation-related sibling tools, so the only signal is the tool's name itself.

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

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

The description discloses no behavioral details such as whether validation is local, calls platform APIs, publishes, or modifies anything. Annotations already mark readOnlyHint=false and destructiveHint=true, so the description needed to clarify side effects but does not. There is no direct contradiction, but the description adds zero behavioral transparency beyond what structured annotations already suggest.

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

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

The description is short and front-loaded, but it is under-specified rather than genuinely concise. Every word is redundant with the tool name, and no 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?

The tool has a full output schema and 100% parameter description coverage, which helps, but the overall intent is too vague. An agent cannot determine what validation is actually performed, what makes validation pass or fail, or how this relates to the sibling validation tools.

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

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

The input schema already documents all parameters at 100% coverage, so the description does not need to repeat them. However, the description adds no nuance about how parameters are used during validation, keeping this at the baseline score.

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?

Tautological: description restates name/title.

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

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

There is no guidance about when to use this tool instead of the closely related validate_media and validate_post_length siblings. The description implies it is for validating post content but provides no context, criteria, or exclusions.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=true, implying possible side effects, but the description says only 'Validate character count' and reveals nothing about side effects, failure behavior, or destructive potential. This could mislead an agent into assuming a pure validation/read-only operation.

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

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

The description is extremely short but not meaningfully concise in the right way; it repeats the title without adding value. Every sentence should earn its place, and this one does not provide any additional 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 validation tool with a destructiveHint, the description is too thin. It doesn't define what a valid character count is, what the tool returns, whether it can mutate or delete content, or how it differs from sibling validation tools. The presence of an output schema does not fully compensate for the missing behavioral and selection 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?

The input schema already provides 100% coverage for the single 'text' parameter with a clear description. The description adds no further detail, but the schema carries the semantic burden adequately.

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?

Tautological: description restates name/title.

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

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

The description provides no guidance about when to use this tool instead of validate_post, validate_media, or other validation-related siblings. There is no mention of context, prerequisites, or selection criteria.

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