ViewPrinter

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

Annotations declare openWorldHint and non-destructive, but the description adds the key behavioral trait: it opens the person's browser and requires their session and consent. The two-call pattern is disclosed, including that a later call reports the connected account. This meaningfully enriches the annotations without contradicting 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?

Two concise sentences with no wasted words: the first states the purpose and the second explains the interactive flow. Everything present 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 output schema exists, the parameter is fully documented, and annotations cover the safety profile. The description covers the critical flow: browser interaction, user consent, and repeated invocation, so an agent knows exactly what 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 schema fully covers the single `platform` parameter with a clear description and enum, so baseline 3 applies. The description adds no extra parameter details beyond what the schema already provides.

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

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

States a specific action ('Connect a social account') and elaborates on the browser-based linking flow. It implicitly distinguishes itself from accounts_list and accounts_performance by describing the connect interaction rather than listing or analytics.

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

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

The description provides clear operational guidance: invoke the tool, let the user sign in externally, then invoke again afterward to get the result. It explicitly notes that the sign-in part 'cannot happen here,' setting correct expectations. It does not name explicit alternative tools or exclusions, but the context is sufficient.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable context beyond annotations: it aggregates accounts across all workspaces and includes workspace and group membership in each result. This clarifies what the agent can expect from the tool's 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?

Three concise sentences front-load the core function, then describe the result contents, then give practical usage guidance. Every sentence adds value 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 zero-parameter, read-only listing tool with an output schema and clear annotations, the description fully covers what the tool does, what it returns, and how to use the results. Nothing essential is missing.

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

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

The tool has zero parameters, so the schema is trivially fully covered and the baseline of 4 applies. The description's guidance about returned ids and group names concerns outputs, not inputs, so no additional parameter semantics are needed.

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

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

The description clearly states the verb and resource: list every social account you can post to, across all workspaces. It also distinguishes the tool from siblings like accounts_connect and accounts_performance by focusing on enumeration and destination naming.

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

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

It explains how to use the results: use returned ids to name post destinations explicitly, or group names to target several accounts at once. It does not explicitly name alternative tools or exclusion conditions, but the usage context is clear.

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

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

Beyond the readOnly/idempotent annotations, it discloses that numbers are from the last sweep rather than live, that each account carries its measurement time, and that unmeasured accounts show no metrics rather than zeroes. It also reveals output ordering, all of which materially affects how an agent interprets results.

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

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

Three short sentences front-load the core output and then add necessary ordering and freshness caveats. There is no filler or repetition of annotation/schema 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?

With an output schema present, the description need not enumerate return fields; it covers the critical context around staleness, missing-data semantics, and ordering. A simple one-parameter tool with strong annotations and schema leaves no meaningful gap.

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

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

The only parameter, period, has a 100%-coverage schema description explaining the window, default, and null-change semantics. The tool description merely echoes 'over the period,' so the schema carries the meaning; baseline 3 is appropriate.

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

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

The description states exactly what the tool reports: per-account followers, posts, total likes, following, and period-over-period movement, with ordering by followers. The title supplies the verb ('Read') and the account-scoped resource distinguishes it from posts_performance and accounts_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 makes its use case clear—reading account performance over 24h/7d—but never states when to prefer it over siblings such as accounts_list or posts_performance, nor does it offer exclusions. The context is reasonably inferable, so it earns an implied-usage score rather than 2.

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 the annotations, the description adds meaningful behavioral constraints: the name must be unique per workspace, matching is case-insensitive, and all accounts must belong to one workspace. This helps the agent anticipate validation failures and use the tool correctly.

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

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

Three short sentences, each carrying distinct useful information: purpose, downstream benefit, and constraints. No filler or repetition; the most important behavior 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?

The description is complete for a low-complexity create operation. It covers purpose, constraints, and relationship to posts_schedule, while the output schema handles return values and the annotations cover safety/idempotency.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds important parameter-level semantics: name uniqueness and case-insensitivity for 'name', and the one-workspace constraint for 'account_ids'. This goes beyond the schema's basic descriptions.

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

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

The description uses a specific verb and resource ('Name a set of accounts') and immediately clarifies the downstream purpose: posts_schedule can use the group name instead of every id. This makes the tool's role distinct from sibling group operations like groups_list, groups_update, and groups_delete.

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

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

The description clearly implies when to use this tool: when you want to bundle accounts so they can be referenced by a single name in posts_schedule. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to decide.

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 destructive, but the description goes further by explaining what is NOT destroyed: accounts stay connected, and scheduled posts are unaffected because posts reference accounts rather than groups. This materially helps an agent understand the real-world impact of the deletion.

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 'Remove a group' and keeps all additional sentences relevant to deletion consequences. It is concise, though the phrase 'only the name and its membership go' is slightly redundant after saying accounts are not touched.

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

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

For a one-parameter destructive tool with an output schema and strong annotations, the description covers the key context: what is removed, what is preserved, and why posts are safe. It does not specify behavior for non-existent groups, but the idempotentHint partially mitigates that concern.

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 the single parameter 'name' with the description 'The group to remove, from groups_list.' The tool description adds no new parameter-level information, so the schema coverage baseline of 3 applies.

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

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

The description starts with a specific verb and resource: 'Remove a group.' It also clarifies the scope by stating that accounts are untouched and posts remain unaffected, which distinguishes it from sibling tools like groups_update or groups_create. This is not a tautology; it adds behavioral specificity.

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

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

The description implies the tool should be used when a group needs to be deleted, and it provides helpful cautionary context about side effects. However, it does not explicitly state when to choose this tool over alternatives or mention any conditions where deletion should be avoided.

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 idempotentHint=true, so the safety profile is covered. The description adds useful behavioral context: it explains the refusal rule for posts and that the tool shows member states and reconnection counts. This goes beyond what annotations provide, though it doesn't discuss pagination or output format (covered by output schema).

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

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

The description is two sentences and packs in purpose, content, and usage guidance without fluff. However, the opening phrase 'Your named sets of accounts' is a bit vague and could be more direct (e.g., 'Lists all account groups'). It's efficient but not perfectly 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 read-only listing tool with no parameters and an output schema, the description is complete. It explains the tool's purpose, what the output contains, and a practical use case. The presence of an output schema covers return format, so nothing essential is missing.

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

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

The tool has zero parameters, so the schema coverage is trivially 100%. The baseline for 0 params is 4. The description correctly implies no inputs are needed and explains what the tool returns, but it doesn't add parameter-specific semantics since there are none to explain.

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 lists account groups and explains what each group contains (members, states, reconnection count). It gives a specific reason for using it (check before posting) which distinguishes it from group mutation tools like groups_create/update/delete. The verb 'list' and resource 'account groups' are explicit, and the description is not a tautology.

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

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

The description explicitly says to check here before composing a post because a post naming a group is refused if any member cannot publish. It also recommends using a group name with posts_schedule instead of listing account ids, which points to an alternative workflow. This gives clear when-to-use and when-not-to-use 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 description explicitly warns that account_ids replaces the entire membership, not an incremental add, and tells agents to omit it to leave members alone. This adds critical behavioral context beyond the annotations, especially the extent of the modification.

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

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

Two tight sentences, front-loaded with the operation summary and then the one subtle behavioral trap. Every clause earns its place.

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

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

With an output schema present and annotations covering mutability, the description covers the action, the full-replacement caveat, and the omit behavior. Nothing needed to call it safely 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 already covers most parameters, and the description reinforces the key account_ids replacement semantics with a clear warning. It also maps 're-describe' to the description parameter, which lacks a schema description, slightly improving 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 concrete actions ('rename', 're-describe', 'change membership') on the group resource, making the tool's function unmistakable. It clearly differentiates from siblings like groups_create, groups_delete, and groups_list by focusing on modifying an existing group.

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

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

The description clearly frames this as the tool for altering an existing group's name, description, or members. It does not explicitly name alternatives, but the context and sibling list make it obvious when to use groups_update versus create/delete.

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 behavioral detail beyond the annotations by stating that size and type are read from storage rather than trusted, and that re-confirming is safe. The idempotentHint annotation already signals retry safety, so the description reinforces it and adds the storage-read insight. No contradiction exists.

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

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

The description is tight and front-loaded: one verb-focused purpose statement, one behavioral fact, and one retry instruction. Every sentence earns its place, and no filler or redundant restatement of the title appears.

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, idempotent confirmation operation, the description is complete: it covers the trigger condition, the retry behavior, and the fact that storage is the source of truth for size and type. The output schema covers return details, and annotations cover mutability and destructiveness.

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?

Two of three parameters have helpful schema descriptions: id is tied to media_upload, and description explains when to provide it and clarifies never overwriting. The kind parameter has no descriptive text, though the enum values offer some meaning. The main description adds little to parameter semantics beyond its general idempotency statement, so with 67% schema coverage a mid-range score 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 action ('Record a file that finished uploading') on a specific resource, and distinguishes this from media_upload and media_update by framing it as the final recording step after upload. The title 'Confirm a media upload' reinforces the purpose and the sibling names are not ambiguous.

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

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

The description gives clear context for when to use it — after an upload has finished — and explicitly says it is safe to call again if the first response was lost. The id parameter description references media_upload, and the description parameter points to media_update for later changes. It lacks a more explicit 'use this instead of X' statement, but the context is clear.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds valuable specifics: it states the deletion is permanent ('cannot be undone') and describes the cascading effect on posts ('any post still using it will lose it'). It also clarifies that the stored bytes are removed, which goes beyond the annotation's binary safety flag. No contradiction with 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 sentences with zero waste. The first sentence front-loads the primary action and scope, and the second sentence immediately conveys the irreversible and cascading consequences. Every clause earns its place; no unnecessary details 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 simple delete tool with a single parameter and output schema present, the description covers the essential behavioral context: permanence and impact on posts. It doesn't discuss error cases or idempotent behavior, but those may be covered by the idempotentHint annotation and output schema. The description is sufficient for an agent to call the tool correctly, though it could have benefited from a brief note on the `id` parameter.

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

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

The schema has one parameter `id` with 0% description coverage, and the tool description does not mention this parameter at all. It does not explain that `id` is the file identifier, nor provide any format or context. Since the description carries no burden for parameter explanation but fails to add any meaning beyond the schema's bare type, it falls short for a low-coverage situation.

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

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

The description uses a specific verb 'Remove' with a clear resource 'a file' and explicitly mentions 'stored bytes,' making the operation unambiguous. It distinguishes itself from siblings like media_update (update) and media_upload (upload) without naming them, because the verb and scope are precise. The title reinforces 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 description implies usage (delete a file) but provides no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It offers a contextual warning about posts losing the file, which hints at consequences but not at selection criteria. There is no mention of 'use media_update instead' or conditions for deletion.

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 supply the safety profile (readOnlyHint, idempotentHint, non-destructive), so the description only needs to add context. It adds ordering behavior (newest first), scope (all uploaded media in workspaces), and the intended use of IDs. It doesn't discuss pagination, limits, or filtering, but the output schema likely 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?

Two efficient sentences: the first states the core behavior and ordering, the second gives a practical usage note. No redundancy, no filler, and the most important information is front-loaded.

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

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

For a parameterless list tool with annotations and an output schema, the description covers the essential context: workspace scope, ordering, and intended use. It could be slightly more explicit about whether all workspaces or only accessible ones are included, but it is not incomplete enough to 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?

The tool has zero parameters, so the baseline is 4. The schema is empty and the description appropriately adds no parameter-specific detail; there is nothing for an agent to misinterpret.

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: listing every file uploaded in the user's workspaces, ordered newest first. It also specifies a concrete downstream use (attaching media to a post), which helps distinguish it from mutating siblings like media_upload, media_delete, and media_update.

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

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

The description gives clear context: use this tool to get media IDs for attaching to a post. It doesn't explicitly name alternatives or exclusion conditions, but the purpose is unambiguous enough for an agent to know when to invoke this list operation versus upload/delete/update 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 description adds meaningful behavior beyond the annotations: sending null clears the description, and the value affects downstream campaign rendering. It also scopes the mutation to the description only. Annotations already indicate a non-read operation with idempotent and non-destructive hints, so no contradiction exists.

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

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

Three tight sentences: the action, a concrete motivating example, null behavior, and a scope boundary. Nothing is wasted and the key behavior is front-loaded.

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

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

For a simple two-parameter metadata update with an output schema and relevant annotations, the description covers purpose, null semantics, and what cannot be changed. No critical information is missing for an agent to invoke it correctly.

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

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

The schema documents the description parameter, but the description adds real meaning: it explains the purpose of the text, provides a concrete example, and clarifies that null removes the current value. The id parameter is self-evident, and the description's example compensates for the incomplete 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 states a specific verb and resource: 'Say what a file shows' — i.e. update a file's description. It clearly differentiates from sibling media tools by noting 'Nothing else about a file can be changed here,' so an agent knows this is not a rename, move, or metadata edit. The scope is precise and actionable.

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

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

It gives clear context for when to use it: describing what a file shows, especially for base images so campaign renders stay consistent. It also states what it is not for ('Nothing else about a file can be changed here'). It does not explicitly name sibling alternatives, but the exclusion is strong enough to route an agent correctly.

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 a non-read-only, non-idempotent operation, and the description enriches this by explaining that bytes go directly to storage, the URL is short-lived, and nothing is recorded until confirmation. This adds meaningful behavioral context 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?

Three concise sentences: purpose, storage behavior, and next step. No filler, information is front-loaded, and every sentence earns its place.

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

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

With an output schema present, the description need not explain return values. It covers the essential flow, the need for confirmation, and the direct-to-storage detail, making it complete for this simple two-parameter 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 parameters are fully documented in the schema (kind and mime_type with examples). The description itself does not add parameter-specific details, but the baseline of 3 is appropriate given high schema coverage.

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

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

The description clearly states the specific action: reserve an id and get a short-lived URL for a PUT. It distinguishes the tool from siblings by describing the two-step flow and explicitly mentioning media_confirm, making its role in the upload pipeline unambiguous.

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

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

It provides clear context: this is the initiation step, and it instructs the agent to call media_confirm after the PUT succeeds. It does not explicitly list when not to use it or compare to media_update, but the workflow guidance is sufficient for a typical upload scenario.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable behavioral context: default output lists all platforms compactly, naming platforms expands to sizes, durations, options, and quirks, and full detail is several times larger.

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 core purpose is front-loaded, followed by parameter behavior, then the recommended usage moment. Every sentence earns its place.

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

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

With an output schema present and annotations covering safety, the description supplies all necessary operational context: default behavior, optional parameter effect, and when to use the tool. 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%, so the platforms parameter is already documented. The description goes beyond the schema by explaining the behavioral effect of omitting it versus naming specific platforms, including the response-size tradeoff.

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 states exactly what the tool does: list what each platform accepts, including media kinds, counts, and caption limit, with optional expanded details. It is clearly distinguishable from sibling tools by focusing on platform rules rather than accounts, groups, media, or 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?

Explicitly advises reading this before scheduling rather than discovering the rules by being rejected. It also explains how to control response size by naming only relevant platforms. It does not explicitly name alternatives, but the usage context is clear and there is no competing platform-rules tool among 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?

While annotations already declare destructiveHint=true and idempotentHint=true, the description adds critical behavioral nuance: already-publishing destinations cannot be recalled and are returned in still_going, and it confirms idempotency with 'Safe to call again.' This goes beyond the hints and provides operational expectations.

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 tightly written sentences. The main action is front-loaded ('Stop a post before it goes out'), followed by essential behavioral details. No filler or redundant phrasing.

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

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

Given the output schema exists (so return values are defined elsewhere) and the description covers cancellation semantics, partial behavior, and idempotency, an agent has everything it needs to call the tool correctly. The description is complete for a destructive action.

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 post_id with 'From posts_list,' and schema coverage is 100%. The description does not add any additional meaning or format details for the parameter, so it relies entirely on the schema.

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

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

The description opens with a specific verb and resource ('Stop a post') and then clarifies the exact behavior (destinations not started are cancelled; already-publishing ones are returned in still_going). This clearly distinguishes it from siblings like posts_schedule and posts_update, which create or modify 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 implies when to use the tool (to cancel a scheduled post) and describes the partial-cancellation behavior, but it does not explicitly name alternatives or state when NOT to use it. The context is clear enough for an agent to infer, but explicit exclusion would elevate it to a 5.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, and the description confirms non-mutating behavior by framing it as a check-before-change tool. It adds behavioral context beyond annotations by disclosing sort order (newest first) and the inclusion of destination delivery states, though pagination or result-size limits are not addressed.

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

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

Two sentences carry the core behavior, the ordering guarantee, and the key usage scenario without wasted words. The most important information is front-loaded and every clause earns its place.

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

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

With no parameters, a true read-only annotation set, and an output schema available, the description covers everything an agent needs: what the result contains, how it is ordered, and why/when to call it. There are no meaningful gaps for invoking 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?

The tool has zero parameters, so there is nothing the description must explain beyond the schema. The description correctly implies the scope is all posts in the user's workspaces, which is sufficient for a parameterless listing call.

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 identifies the resource (posts in workspaces) and the operation (listing), and adds distinctive details: newest-first ordering and per-destination delivery state. It clearly differentiates this listing tool from mutation siblings like posts_update and posts_cancel.

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

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

It explicitly says when to call this tool: to check whether something published and before changing or cancelling anything. It also names the sibling tools that depend on the post_id obtained here, so an agent knows this is the lookup step before mutations.

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 the readOnly/idempotent annotations, the description explains data freshness ('as of the last sweep'), absence semantics ('no metrics at all rather than zeroes, sorts last'), the distinction between null and 'unavailable', and the cross-platform comparability caveat for avgWatchMs. No contradiction with 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 long but dense; the first paragraph front-loads the core result set and ranking behavior, and the second paragraph organizes the insights object, null handling, and platform caveats. Every sentence adds necessary context for interpreting performance data.

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

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

For a complex performance-read tool, the description covers measurement timing, missing data semantics, per-platform analytics aggregation, video retention details, and cross-platform comparison pitfalls. With an output schema present and annotations declaring read-only/idempotent behavior, nothing essential is left unexplained.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds operational meaning: 'Best first' explains the default by=value behavior, and 'Sort by change instead' clarifies when to choose by=change. It reinforces delivery-absence semantics for ranking without duplicating the schema.

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

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

The first sentence clearly identifies the resource ('published posts') and the kind of information ('how they are performing, one row per destination') with specific metrics. It doesn't explicitly name or contrast with sibling tools like accounts_performance or posts_list, so it stops short of full sibling differentiation.

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

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

It gives clear guidance on choosing ranking behavior: 'Best first, so the default answers what did well in one call' and 'Sort by change instead to find what is moving now.' It lacks explicit when-not/use-this-other-tool instructions, but the context is clear.

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

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

Annotations only say readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds substantial behavioral context: nothing publishes yet, publishing must be enabled on the account, if not enabled it saves nothing and says so, group expansion is frozen at scheduling time, and media is either video or images never both. It also warns not to tell the user it's saved until the call returns successfully. This goes well 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 dense but every sentence adds information. It front-loads the core action and then covers draft behavior, account/group selection, media constraints, scheduling, publishing requirements, and a user-facing warning. It is longer than average, but the tool is complex with 8 parameters and nested platform options, so the length is justified. Slight redundancy with the schema's draft description exists but the description adds the posts_update routing.

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

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

For a complex tool with 8 parameters, nested objects, and an output schema, the description covers the key decision points: draft vs publish, account/group selection, media type constraints, scheduling, workspace constraint, publishing enablement, and idempotency retry behavior. The output schema exists, so return values don't need to be described. The only minor gap is not detailing every platform option, but the description explicitly routes to platforms_list for that.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema: it explains the draft flag's relationship to posts_update, clarifies that groups are expanded at scheduling time, states that a post is either video or images, and notes that naming neither accounts nor groups is refused. It doesn't enumerate every platform option, but the schema already covers those and the description points to platforms_list for semantics.

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

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

The description opens with a specific verb and resource: 'Create a post and queue it for every account named.' It clearly distinguishes this from siblings like posts_update (promotes drafts) and posts_cancel, and explains the draft behavior. The title 'Schedule a post' is expanded with concrete scope and semantics.

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: use draft true to hold the post, use posts_update to promote it, name accounts from accounts_list or groups from groups_list, and explains how groups expand. It also states constraints like 'Accounts must all be in one workspace' and 'Omit scheduled_at to send as soon as possible.' This is rich routing and usage context.

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

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

Annotations already set readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false. The description goes far beyond these by explaining nuanced behaviors: draft promotion requiring publishing permission, destination expansion semantics, re-aiming delivery via scheduled_at, and the retry behavior for failed destinations. No contradictions with annotations; it adds substantial context.

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

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

The description is front-loaded with the core purpose in the first sentence, but it is a dense wall of text. While every sentence carries important information, the lack of bullet points or paragraph breaks reduces scannability. It is appropriately sized for the complexity but could be more structured for easier parsing.

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 six parameters and complex behaviors (draft promotion, destination expansion, retry logic, post-publication restrictions), the description covers all operational scenarios comprehensively. The presence of an output schema means return values need not be described, and nothing an agent needs to correctly invoke the tool is missing.

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

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

Schema description coverage is 100%, yet the description adds meaningful semantics beyond each field's basic definition. For example, it clarifies that groups are expanded immediately (not live-linked), that account_ids replace the entire destination list, and that scheduled_at in the past sends as soon as possible. This enriches the agent's understanding of parameter interactions.

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

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

The description clearly states the tool's purpose: 'Change a post that has not gone out yet: its caption, its time, its destinations, or whether it is a draft.' This is specific and distinguishes it from siblings like posts_cancel (cancel) and posts_schedule (schedule new), making selection 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?

Provides explicit guidance on when and how to use the tool: it explains that editing is always allowed but sending a draft requires publishing enabled, and that caption/destinations can only be changed before anything publishes. It also details how to retry failed destinations, covering exclusion criteria and alternative behaviors without needing to reference sibling tools.

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