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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds only the constraint that the group must be 'existing'; it says nothing about what happens to connections already present, whether duplicates error or are ignored, or why the non-idempotent hint matters for repeated calls.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though its brevity contributes to the informational gaps noted in other dimensions rather than reflecting deliberate density.

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

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

For a two-parameter mutation with full schema coverage, complete annotations, and no output schema, the definition is minimally viable. Missing is any statement of duplicate-handling behavior or failure conditions, which an agent would want before invoking a non-idempotent write against an existing group.

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 'id' documented as 'Group ID' and 'connectionIds' as 'Connection IDs to add', so the schema carries full parameter meaning. The description confirms the connections belong to an account group but adds no format, batching limits, or ID-source detail beyond the schema. Baseline 3 applies.

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

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

The description states a specific verb (add) and resource (social connections) applied to a scoped target (an existing account group), which is enough to distinguish it from sibling mutations like create_account_group or remove_connections_from_group. It doesn't explicitly name the inverse sibling, but the verb contrast is unambiguous.

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

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

There is no when-to-use guidance, no mention of prerequisites (the group must pre-exist, implied but not stated as a condition), and no reference to alternatives such as remove_connections_from_group or create_account_group. The agent must infer usage from the name alone.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent, open-world write, so the safety profile is covered. The description adds the downstream behavior that imported posts become repurposable social content, but says nothing about what happens immediately on connect, duplicate-source handling (notable given idempotentHint=false), or that apiKey is required for protected sites.

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

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

Two short sentences with zero redundancy, the action front-loaded and the rationale second. 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?

For a six-parameter mutation tool with full schema coverage, annotations, and no output schema, the description is nearly sufficient. The remaining gap is post-call expectations — whether connecting triggers an immediate sync or only schedules one — which the description leaves unaddressed.

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

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

Schema description coverage is 100%, with all six parameters documented including two enums and defaults ('default weekly'), so the schema does the heavy lifting. The description adds no meaning beyond the schema — it never mentions autoImport, importFrequency, or apiKey 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 names a specific verb ('Connect') and resource ('a WordPress site or RSS feed as a content source'), matching the enum values in the schema. It is clearly distinguishable from siblings like list_content_sources, delete_content_source, and fetch_source_content, though it never names those alternatives explicitly.

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

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

Usage is only implied through the lifecycle framing ('Imported posts can then be repurposed into social content'), which tells the agent why you'd add a source but not when to prefer it over, say, repurpose_content or fetch_source_content. No prerequisites, ordering, or exclusions are stated.

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

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

Annotations only declare the safety profile (destructive, open-world, non-idempotent); the description adds what they cannot — per-row independence with partial-failure semantics ('one bad row fails alone'), the 50-row ceiling, the shape of the per-row result (ids, warnings, edit links), and a platform-specific rejection rule for X links. The X billing rationale explains why the API rejects link posts, which is genuinely actionable behavior rather than restated metadata.

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?

Front-loaded with the batch purpose, then defaults behavior, failure semantics, limits, return shape, then the platform caveat. Every sentence carries information, though the X rule runs long and the pricing detail, while useful justification, is the most expendable clause.

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, open-world, non-idempotent bulk mutation with nested arbitrary payloads and no output schema, the description covers limits, partial-failure behavior, merge precedence, and the return shape. An agent has everything needed to size a call and interpret the result without guessing.

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 documents the merge precedence for `defaults`, so most parameter meaning is carried there. The description still adds value by naming the practical defaults (campaign, connectionIds, timezone) and, more importantly, by tying the X link restriction to the platformContent.twitter field, which the schema does not mention.

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?

Opens with a specific verb plus resource and scope: 'Create a whole campaign of posts from one manifest.' It immediately distinguishes itself from the sibling create_post by explaining that each entry accepts the same fields as create_post, so an agent knows this is the batch form of that tool without opening either schema.

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

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

The batch context and the 'Max 50 per call' cap give clear conditions for use, and the create_post reference implies the single-post alternative. It never explicitly says 'use create_post for a single post,' so the routing is implied rather than stated, which keeps this short of a 5.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the mutation profile is covered structurally. The description adds the outcome concept (a reusable target set for posts) but says nothing about name uniqueness, error behavior on duplicates, or required permissions, which matters for a non-idempotent create.

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

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

A single sentence that front-loads the action and follows with a concrete example and the reason it matters. No filler, no restatement of the tool name.

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 five-parameter create tool with annotations covering safety and no output schema, the description covers what is created and why. It leaves return-value expectations (e.g. whether a new group ID comes back) and duplicate-name behavior unstated, but that is a modest gap given the structured coverage.

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

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

Schema description coverage is 80%, so the schema documents name, color, isDefault and connectionIds on its own. The description reinforces 'named' and the connection-bundling intent, but the undocumented 'description' parameter receives no clarification and no format or constraint details are added.

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 gives a specific verb and resource ('Create a named account group') and explains the resulting behavior ('bundling social connections, so future posts can target the whole set at once'). The 'Create' verb naturally separates it from update_account_group and add_connections_to_group, though no sibling is named explicitly.

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

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

Usage is only implied through the stated benefit of grouping connections for targeting. There is no guidance on when to create a new group versus adding connections to an existing one via add_connections_to_group, and no mention of prerequisites like available connection IDs from list_connections beyond the schema hint.

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 destructive/openWorld/non-idempotent, so the bar is lower, yet the description adds real behavior the schema cannot: X rejects any link at $0.20 vs $0.015 billing, and TikTok scheduling without privacyLevel returns a 400. These are non-obvious failure modes that materially change how the agent builds the call.

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?

Front-loaded with the core action in the first sentence, followed by platform caveats in a compact, scannable order. It is dense but every clause carries operational information; the X billing rationale is slightly verbose for a tool description but justifies its length by explaining why the constraint exists.

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 14-parameter, nested-object mutation tool with no output schema, the description omits what a successful call returns (post ID? status?) and says nothing about auth or approval workflow despite a submit_for_approval sibling. The platform-specific rules it does include are strong, but the post-call picture is incomplete.

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

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

Schema description coverage is 100%, so the schema already documents all 14 parameters, including the schedule-vs-scheduledFor precedence and the platformContent shape. The description's only addition is pointing at platformContent.twitter as the place for a link-free X version, which is a small but useful semantic nudge beyond 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?

The first sentence states a specific verb and resource (create a social media post) plus the two outcome modes (draft or scheduled). It does not explicitly route the agent away from bulk_create_posts or distinguish when to preview first, so sibling differentiation is only partially achieved via the carousel note.

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

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

The description implies when to use it (draft vs schedule, per-platform constraints) and points to generate_carousel/render_carousel for carousels, which is genuine alternative routing. However, it never addresses create_post versus bulk_create_posts, preview_post, or submit_for_approval, so the primary selection question is left to inference.

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

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

Annotations already cover the safety profile (non-read-only, non-idempotent, non-destructive), and the description adds genuinely useful context beyond them: the call is asynchronous and returns a render ID rather than a finished asset, so the agent must poll. It does not mention render duration, failure modes, or whether duplicate submissions create duplicate jobs (notably relevant given idempotentHint=false).

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

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

Two tight sentences, front-loaded with the action and followed immediately by the return contract and the required follow-up. Every clause carries information; nothing is redundant with the title or annotations.

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

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

With no output schema, the description correctly carries the burden of describing the return value (a render ID, later a video URL) and the polling loop the agent must drive. For a nested-object, async render tool the picture is nearly complete, lacking only expected job duration or failure handling.

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 templateId, fields, and aspectRatio all self-documented including the nested field-value object and the default-ratio behavior. The description adds no parameter-level detail beyond what the schema already supplies, 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?

States a specific verb and resource ('Submit a video render job') plus the source of the render ('from a template'), which cleanly separates it from generate_image, render_carousel, and create_post among its siblings. An agent can identify the operation without opening the schema.

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

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

Gives explicit next-step routing: poll get_video_status until status is 'completed', then use the returned URL as post media — that is real when-to-use context and names the sibling to hand off to. It does not state when NOT to use it (e.g. versus render_carousel or generate_image for non-template output), which keeps it short of a 5.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is known. The description earns credit for disclosing the blast radius — the underlying social accounts are not disconnected — which is the key behavioral question for a destructive group deletion. It stops short of stating irreversibility, what happens to posts/schedules tied to the group, or required permissions.

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

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

One short sentence with the action front-loaded and the scope caveat immediately after it. No filler, no redundancy with the title or annotations.

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

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

For a one-parameter destructive tool with no output schema, the definition covers what an agent most needs: the action, its target, and the fact that connected social accounts survive. Only the irreversibility and downstream effects of the deleted group are left unstated.

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

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

Schema coverage is 100% with a single required 'id' documented as "Group ID", so the schema carries the parameter meaning. The description adds nothing about id format, where to obtain it, or behavior when the id is unknown, so the baseline 3 applies.

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

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

States a specific verb and resource ("Delete an account group") and scopes the effect with a parenthetical about social accounts. It is distinguishable from sibling mutators like remove_connections_from_group, but it never explicitly routes the agent away from those alternatives.

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

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

Usage is only implied by the verb: an agent can infer this is the tool for removing a group. There is no explicit when-to-use versus when-not, no mention of prerequisites, and no pointer to list_account_groups or get_account_group for resolving the id.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that — it does not say whether imported content from the source is also purged, whether the deletion is reversible, or whether confirmation/ownership is required, which are the material unknowns for a destructive 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?

A single short sentence, front-loaded and free of filler, but it is under-specified rather than efficient — the terseness costs information an agent needs for a destructive call.

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 tool with no output schema and cascade implications for imported content, the definition is materially incomplete: it leaves open what gets destroyed downstream, whether retries are safe given idempotentHint=false, and what to do on failure. The annotations carry the safety signal but not the operational consequences.

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

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

With one parameter at 100% schema description coverage, the schema already documents the id field as "Content source ID." The description only echoes the resource name and adds no format, sourcing, or lookup guidance, 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?

"Remove a content source" states a specific verb and resource, which is enough for an agent to know it deletes a content source record by ID. It does not differentiate from nearby siblings like delete_post or delete_account_group, or clarify its relationship to list_content_sources/add_content_source, but the resource name is unambiguous on its own.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of the alternatives (remove_connections_from_group-style surgical removal vs this full delete). The agent must infer entirely from the tool name when deletion is appropriate versus adding/listing a source.

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, idempotentHint=false, and readOnlyHint=false, so the safety profile is known. The description adds nothing beyond them — no statement of irreversibility, no confirmation/permission requirements, and no clarification of what scope the deletion applies to.

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

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

The single sentence is front-loaded and free of padding, but it is under-specified rather than genuinely concise. There is no second sentence carrying the information an agent actually 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?

The tool itself is simple (one required string param, no output schema), but the description leaves the singular-vs-plural sibling ambiguity unresolved and provides no irreversibility note for a destructive operation. For a delete tool, that is a significant omission.

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

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

Schema description coverage is 100% and the single parameter 'id' is documented with "Post ID to delete." The description adds no meaning beyond the schema, so the baseline 3 applies.

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

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

"Delete a post" names a specific verb and resource, but it essentially restates the tool name and title. It never distinguishes this single-post delete from the sibling delete_posts, which is the main ambiguity an agent would face.

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

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

There is no when-to-use guidance at all: no mention of when to choose this over delete_posts, no prerequisites, and no note that this is irreversible. Usage must be inferred entirely from the name.

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

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

Annotations already flag destructiveHint=true and readOnlyHint=false, but the description adds substantive context beyond them: a filter is mandatory so it can never wipe everything, published/processing posts are always excluded regardless of status, and the default mode is a dry run unless confirm:true. These are non-obvious safety guarantees an agent could not infer from the schema or annotations alone.

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: purpose first, safety constraints second, required workflow last. No filler, and the most decision-critical information (dry-run default) appears before the schema is ever opened.

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 bulk mutation with no output schema, the description covers everything an agent needs: what matches, what is protected, what happens without confirm, and the expected call sequence. Nothing material is left to 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 coverage is 100%, so the baseline is 3; the description adds meaning by framing filter params (ids/label/status/campaign) as a mandatory constraint and by clarifying that published/processing are excluded no matter what status is passed, which sharpens the documented default. It does not add syntax details beyond the schema, so it modestly exceeds baseline rather than fully replacing it.

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

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

States a specific verb and resource plus scope: "Bulk-delete posts matching a filter — e.g. every draft in a campaign." The word "bulk" combined with the filter requirement makes it distinguishable from the singular delete_post sibling, and the example grounds what a match looks like.

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

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

Gives an explicit operating procedure: "Always call once without confirm to see what matches, show the user, then confirm." That routes the agent through dry-run-first usage and away from one-shot deletion, which is exactly the when/how guidance this destructive tool needs.

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

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine context beyond them: the import is incremental ('latest content'), triggered immediately ('right now'), touches an external source type, and produces results that must be read via list_imported_content. It stops short of describing failure behavior or what happens on repeated calls.

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

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

One sentence, zero filler, with the action front-loaded and the follow-up step placed at the end where it is actionable. Every clause contributes 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, non-destructive, no-output-schema tool, the definition covers what it does, that it acts immediately, and how to observe the result. The remaining gap is modest: no indication of whether the import is synchronous, what happens for an invalid or disconnected source, or how long it may take.

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

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

There is a single required parameter with 100% schema description coverage ('Content source ID'), so the schema already carries the parameter meaning. The description only implies that the ID refers to a source rather than adding format, sourcing, or discovery guidance. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description names a specific verb and resource ('Import the latest content from a source') and grounds it with a concrete example ('new WordPress posts'), so an agent knows this pulls new items rather than listing or managing sources. It does not explicitly distinguish itself from adjacent siblings such as add_content_source or list_content_sources, which keeps it short of a 5.

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

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

'right now' establishes this as an on-demand pull rather than a scheduled or configuration operation, and the sentence closes with the exact next step ('then list it with list_imported_content'), giving a clear call sequence. There is no explicit when-not guidance or mention of alternatives for retrieving already-imported content besides the named follow-up.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, openWorldHint=false and destructiveHint=false. The description adds genuine value by clarifying that this stage produces text only, preventing the agent from expecting images, but it does not disclose that each call is non-idempotent and will yield different slides, whether any draft is persisted server-side, or any cost/latency profile for the generation step.

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, both earning their place, with the text-vs-image boundary front-loaded and the handoff to render_carousel placed second. No filler or restatement of the tool name.

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 five-parameter generator with a fully documented schema and no output schema, the description covers purpose, scope, and pipeline position adequately. It could do slightly more on what the returned slide text looks like (count relative to maxSlides, structure) and whether state is persisted between this call and render_carousel.

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 per-parameter descriptions, defaults, ranges and two enums, so the schema already carries parameter meaning. The description adds no parameter-level detail at all — nothing on how style and platform interact, or what brandColors influences at the text stage versus the render stage. Baseline 3 applies.

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

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

The description states a specific verb and resource — 'Generate carousel slide TEXT (title/content/quote/CTA) from long-form content' — and immediately scopes it against the sibling that produces images. An agent can distinguish generate_carousel from render_carousel without opening either schema.

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

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

It gives a clear usage context (decompose long-form content) and an explicit next-step routing: 'Then call render_carousel to turn the slides into branded PNG images.' What's missing is any exclusion — nothing says when NOT to use it (e.g. vs. repurpose_content, or short-form sources) or what to do if the returned text is unsuitable.

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 declare the generic profile (not read-only, not destructive, not idempotent); the description adds the genuinely useful facts: it consumes 1 AI credit and returns an image URL that must be routed onward. That credit cost is the key operational signal for a non-idempotent call and is not recoverable from the annotations. It stops short of covering failure behavior or whether credits are charged on a failed generation.

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, front-loaded sentences with no filler: capability, cost, then return-and-route. The final clause ("pass it through upload_media/create_post media flow") is slightly telegraphic but still parses 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?

With no output schema, the description correctly carries the return value (an image URL), and it discloses the credit cost. The remaining gap is dimensional parameters plus any statement of size limits or defaults, which matters for a tool that silently accepts width/height.

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 only 50%: prompt and style are documented in the schema, but width and height have no description at all. The description adds nothing about these — no units (pixels), no defaults, no aspect-ratio or model-limit guidance — so an agent has to guess at valid values for two of four 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?

"Generate an image with AI (DALL-E)" names a specific verb and resource, and "for use in posts" scopes it against image-adjacent siblings like generate_carousel, render_carousel, and create_video without ambiguity. An agent can tell immediately what this produces.

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 a clear downstream routing instruction — pass the returned URL through upload_media/create_post media flow — which effectively tells the agent this is a generation step, not a publish step. It lacks an explicit when-not-to-use clause (e.g. versus generate_carousel for multi-image assets or upload_media for existing files).

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the description correctly spends its words elsewhere: case-insensitive name resolution with exact-match preference then substring fallback, and the ambiguous-name behavior (HTTP 300 returning candidates). That error-path disclosure is real value beyond the annotations, though permissions or rate-limit context is absent.

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: what it fetches, what it returns and where that output goes next, then resolution/error semantics. Nothing is repeated and the primary purpose 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 two-parameter read tool with no output schema, the description supplies the essentials: return shape (connectionIds[]), name-matching rules, and the ambiguous-result response code. An agent has enough to call it and handle both success and the 300 case.

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

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

Schema coverage is 100%, so the baseline is 3; the description raises it by explaining the matching algorithm and priority order for idOrName, which the schema's 'Mongo ObjectId or group name' does not. It also clarifies the interplay between default and idOrName, beyond the schema's 'ignore idOrName' phrasing.

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

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

States a specific verb and resource ('Fetch one account group') and enumerates the three lookup keys (id, name, default flag), which cleanly separates it from the sibling list_account_groups. An agent can pick this over the list tool without reading either schema.

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

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

Makes the intended downstream flow explicit: the returned connectionIds[] 'can be passed straight to create_post', naming the consuming sibling tool. It does not explicitly exclude alternatives such as list_account_groups when the id is unknown, which keeps it short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data and the description carries a lower burden. The description adds the metric set, which is genuine context, but says nothing about aggregation granularity (per post vs. aggregate), pagination behavior, or what happens when dates are omitted despite all five parameters being optional.

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

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

A single front-loaded sentence with no filler; the metric enumeration is the useful payload. It is efficient but arguably under-specified rather than maximally concise, since a short clause on return shape could have been added without bloat.

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 five all-optional parameters, no output schema, and no nested objects, the description should explain what the response looks like (per-post rows vs. totals) and what the default scope is when no dates or platform are supplied. It leaves both open, so an agent cannot predict the result set before calling.

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 every parameter (page, limit, startDate, endDate, platform) is already documented in the schema and the baseline of 3 applies. The description adds no meaning beyond that — notably it does not clarify the platform value domain or the default date window when startDate/endDate are omitted.

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

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

States a specific verb and resource ('Get post performance analytics') and enumerates the metrics returned (impressions, likes, comments, shares), which is far more informative than the bare name. It implicitly separates itself from sibling reporting tools like get_delivery_report and get_revenue_overview by scoping to post-level engagement, but it never names those alternatives, so the differentiation is left to inference.

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

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

There is no when-to-use guidance, no stated prerequisites (e.g. whether a connection or published post is required), and no mention of the reporting siblings an agent might otherwise pick. The agent must guess whether this is the right tool for account-level or campaign-level reporting.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered. The description adds genuinely new behavioral context: the check reflects a human decision, the result set is a fixed four-state enum, and the intended use is polling — valuable since there is no output schema. It omits polling interval or rate-limit guidance.

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, no waste, with the core purpose and the enumerated outcomes front-loaded before the polling instruction.

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 read tool with no output schema, the description supplies purpose, return states, and the triggering predecessor — essentially everything needed to call it. Only polling cadence and a pointer to list_pending_approvals are 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% and approvalId is already documented as coming from submit_for_approval, so the description adds no new parameter meaning. Baseline 3 applies when 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?

States a specific verb and resource ("Check whether a human has decided on a submitted approval") and enumerates the possible outcome values (pending / approved / rejected / changes_requested), which lets an agent distinguish it from submit_for_approval and list_pending_approvals without opening a schema.

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

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

"Poll this after submit_for_approval" gives explicit sequencing guidance and names the predecessor tool. It stops short of saying when to stop polling or how it differs from list_pending_approvals, so it is clear but not exhaustive.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value by disclosing the data source (the user's engagement history), but it says nothing about what happens when history is sparse or absent, or how fresh the data is — a meaningful gap for a recommendation tool.

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

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

Two short sentences with zero waste: purpose first, then the usage rule. The most decision-relevant information (call before create_post) is front-loaded after the core statement.

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

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

With no output schema, the description carries the burden of explaining what comes back, and 'best times' is underspecified — it is unclear whether the result is a list of hour slots, weekday recommendations, or per-platform objects. For a low-complexity single-parameter read tool this is tolerable, but an agent cannot anticipate the response shape.

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

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

Schema description coverage is 100%, so the single 'platform' parameter is already documented in the schema, making 3 the baseline. The phrase 'per platform' implies that omitting the parameter returns results for all platforms and that supplying it narrows to one, which is a small addition beyond the schema but not a substantive one.

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

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

States a specific verb and resource ('Get the best times to post') and adds the derivation basis ('based on the user's engagement history') plus per-platform scope. It is clear on its own, but it does not differentiate itself from nearby scheduling siblings such as suggest_schedule or get_posting_schedule, so an agent must infer the boundary.

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

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

Explicitly tells the agent when to call it: 'Use before picking scheduledFor in create_post,' which ties the output directly to a downstream parameter. There are no when-not-to-use rules and no mention of the overlapping suggest_schedule tool, so the routing guidance is clear but not exhaustive.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the safety profile is covered. The description adds value beyond that by disclosing what the call returns (a ready-to-use system prompt) and how it is meant to be applied, which matters because there is no output schema. It does not cover failure behavior for an unknown voice ID.

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

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

One sentence, front-loaded with the verb and resource, with the purpose clause appended after an em-dash. No redundant or filler 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 single-parameter, idempotent read tool with full schema coverage and no output schema, the description covers what it does, what it returns, and when to use it. The only minor gap is behavior on an invalid or missing voice ID.

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

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

Schema description coverage is 100% and the single 'id' parameter is already documented with a cross-reference to get_brand_voices. The description adds no additional meaning about the parameter, so the baseline of 3 applies.

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

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

The description names a specific verb and resource ('Get the ready-to-use system prompt for a brand voice'), which is clearly distinct from the sibling get_brand_voices that enumerates voices. It stops short of explicitly contrasting with that sibling in the description text (the pointer to get_brand_voices lives only in the schema), so it is clear but not fully self-differentiating.

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 concrete usage context: apply the returned prompt when writing posts so content matches the user's tone. There are no explicit when-not conditions or named alternatives, but the intended invocation context 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?

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the description's burden is lower. It adds that brand voices are tone-of-voice profiles analyzed from the user's content and are scoped to 'the user's' voices, but says nothing about ordering, pagination, or result shape.

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

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

A single front-loaded sentence with a short parenthetical that explains the resource. Every phrase earns its place and there is no repetition; it is appropriately sized for a zero-parameter list tool.

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

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

For a zero-parameter, read-only list tool whose annotations cover safety, the description gives enough context to know it lists the user's brand voice profiles. It could clarify return ordering/pagination or when to call get_brand_voice_prompt instead, but no output schema exists and complexity is low.

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

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

There are zero parameters, so the baseline is 4. The description appropriately adds no parameter-level detail because none exist.

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

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

States a specific verb and resource: 'List the user's brand voices.' The parenthetical clarifies that these are tone-of-voice profiles analyzed from content, distinguishing it from post/campaign siblings, though it does not explicitly contrast with get_brand_voice_prompt.

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

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

Usage is implied as a read-only listing of the authenticated user's brand voices. There is no explicit when-to-use or when-not-to-use guidance, and it does not mention related alternatives such as get_brand_voice_prompt or list_brand_kits.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuine value beyond that by disclosing the return shape — assets are full media attachments with id/type/url/key/filename/mimeType/size in slide order — which is essential given there is no output schema. It does not describe the status field or its possible values.

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

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

Two tight sentences, with the action front-loaded and the follow-up workflow second. Every clause carries information the agent needs, 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?

With no output schema, the description does well to enumerate the asset fields, but it only covers the completed state. An agent polling this tool would benefit from knowing what the status values are and how in-progress or failed renders appear, which 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% and the single parameter already documents itself as the render ID from render_carousel. The description adds no parameter-level detail beyond the schema, which is the expected baseline for full coverage.

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

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

States a specific verb and resource: 'Check a carousel render job.' This clearly separates it from the sibling render_carousel (which initiates the job) and is reinforced by the schema note 'Render ID from render_carousel.' It stops short of explicitly naming the counterpart it pairs with in prose, so it is clear but not fully sibling-differentiated.

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

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

Gives explicit downstream guidance: pass the returned assets straight into create_post's media array to draft or schedule the post, which tells the agent both the follow-up tool and the purpose. It does not say how often to poll, what to do while the render is still running, or how to handle a failed render.

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 that this is a safe, read-only, idempotent operation. The description adds meaningful behavioral context: the generated link must be opened by the user in a browser because OAuth cannot be completed autonomously. It does not mention link expiration or single-use behavior, but the core human-in-the-loop trait is disclosed.

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

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

The description is a single, front-loaded sentence with no filler. Every clause contributes either the action, the user-browser requirement, or the reason it must be sent to a human.

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 link generator with a fully described single parameter and no output schema, the description covers the essential context an agent needs. It could optionally mention link expiry or that the connection is only completed after the user finishes OAuth, but it is largely 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 fully documents the single 'provider' parameter with an enum and a clear description. The tool description does not add syntax or selection guidance beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb ('Generate') and resource ('a link') and explains the exact purpose: connecting a new social account. It is clearly distinct from sibling tools like list_connections because it focuses on initiating a new OAuth connection rather than listing existing ones.

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 usage context: use this when a user needs to connect a new social account and OAuth requires human browser interaction. It does not explicitly name alternatives or when not to use it, but the intended scenario 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower; the description still adds real behavior: the `days` look-back applies only to failures and connection changes, while approvals use a fixed 48 h window and scheduled-post preflight uses 7 days. It also surfaces a return-field convention (`hasIssues`) that no output schema documents, though it does not describe the result shape beyond that flag.

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?

Front-loaded with the one-line intent ('the morning check'), followed by a dense but purposeful enumeration and two short closing sentences on provenance and the empty-result signal. The category list is long but every clause maps to distinct coverage, so nothing is padding; a bulleted list would read slightly better than the single run-on sentence.

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 multi-domain aggregate with one optional parameter and no output schema, the description covers what sections exist and how to interpret an empty result, which is the decision-critical information. It leaves the exact per-section response fields undocumented, a modest gap given there is no output schema to fall back on.

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 defines `days` as a 1–30 day look-back with default 1, so baseline is 3. The description adds meaning by scoping it: the window governs failures and connection health changes only, not the fixed 48 h approval and 7-day scheduling windows, which prevents the agent from assuming a single global time filter.

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?

Names a concrete deliverable ('morning check') and then enumerates exactly what it aggregates: failed/partially failed posts with per-platform errors, dead or degraded connections, approvals pending within 48 h or expired, at-risk scheduled posts, stalled content sources, and queues with free slots. The scope is distinguishable from siblings like list_pending_approvals or retry_failed because it is explicitly a cross-domain digest rather than a single-resource query.

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?

Frames the usage context strongly ('the morning check', 'same data as the 08:00 digest e-mail') and tells the agent what an empty result means ('hasIssues: false means nothing to do'). It stops short of explicitly naming alternatives for drilling into a single category (e.g. use list_pending_approvals for just approvals), so the when-not is only implied.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description contributes nothing beyond that — it does not say what "details" encompasses, whether missing IDs error or return empty, or whether the result includes related entities. With annotations carrying the safety burden the bar is lower, but zero added behavioral context on a read tool still lands at 2.

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

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

One sentence, action-first, with no filler or hedging. Nothing in it is redundant, though it is also the absolute minimum for 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 single-parameter read tool with rich annotations, the definition covers the mechanics of invocation. The gap is the return payload: there is no output schema, so "details" is undefined and the agent cannot anticipate fields like status, scheduled time, or account targets.

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 sole parameter is documented as "Post ID", so the schema does all the work. The description only restates "by ID" without adding format hints (numeric vs UUID) or indicating whether the ID must come from list_posts. Baseline 3 applies when the schema is complete.

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

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

"Get details of a specific post by ID" states a concrete verb (get) and resource (post) plus the lookup key, so the operation is unambiguous. It does not distinguish itself from near siblings such as preview_post, list_posts, or get_carousel_render, which is the only thing keeping it from a 5.

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

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

There is no guidance on when to reach for this tool versus preview_post (which presumably also renders a single post) or list_posts. The agent is left to infer that this is the fetch-single-record path purely from the word "specific".

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds meaningful behavioral context beyond annotations: the schedule:read permission, the user's timezone, the inheritance rule for groups without overrides, and the slot format.

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 three tight sentences with no wasted wording. The core purpose is front-loaded, followed by data format and permission details.

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

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

For a zero-parameter read-only tool with no output schema, the description supplies the key return semantics: global schedule plus per-group overrides, slot shape, timezone, and inheritance behavior. It also states the required permission, leaving little an agent needs to call 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 tool has zero input parameters, so the baseline is 4. The description adds helpful meaning about returned slot formatting and inheritance, but there are no input parameters whose semantics need explanation.

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: 'Read the weekly posting queue schedule: the global schedule plus any per-group overrides.' The scope is clear, but it does not explicitly distinguish this tool from nearby siblings such as set_posting_schedule, get_best_times, or suggest_schedule.

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 context about what the schedule contains and a prerequisite permission, but never states when to use this tool instead of set_posting_schedule, get_best_times, or suggest_schedule. Usage is implied by the read-only framing rather than explicitly guided.

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, destructiveHint=false, and openWorldHint=false, so the description's trailing 'Read-only' is redundant. It does add genuine context by naming the upstream providers from which data is aggregated, but says nothing about network/credential requirements per provider, rate limits, or empty-result 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?

It is a single front-loaded sentence that lists the three output components in priority order, with no filler. The only wasted token is the redundant 'Read-only' tag at the end.

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

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

With no output schema, the description usefully enumerates the returned sections (totals, trend vs previous period, transactions, MRR), which is the key thing an agent needs. It is thin only on edge cases — no note on which provider lacks which metrics (e.g., Shopify has no MRR) or on behavior with zero connections.

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% — every one of the four parameters has a documented purpose and default in the schema. The description only gestures at the feature set (MRR, transactions) that the includeMrr and includeTransactions flags control, adding little beyond what the schema states.

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 gives a specific verb and resource — 'Get revenue analytics' — and enumerates the payload: totals, period-over-period trend, recent transactions, and MRR from Stripe/RevenueCat/Shopify. That level of detail distinguishes it from the generic sibling get_analytics without naming it explicitly, which keeps it just short of a 5.

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

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

Usage is implied rather than stated: an agent can infer this is the tool for revenue questions, but the description never says when to prefer it over get_analytics or what to do if no providers are connected. No exclusions or alternatives are offered.

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

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

Annotations already declare readOnly, idempotent, non-destructive behavior, so the description earns credit for adding genuinely new context: completed renders return presigned download URLs for both video and thumbnail, and those URLs expire in roughly one hour. That expiry detail is important operational knowledge absent from structured fields. It does not cover behavior for non-completed states (pending, processing, failed), which is the main remaining gap.

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

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

Two sentences, front-loaded with the purpose, followed by the one detail an agent cannot get from structured fields. Nothing is padded or repetitive.

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

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

There is no output schema, so the description bears responsibility for describing the response. It explains the completed case well, including URL expiry, but never enumerates the possible status values or says what the payload looks like while a render is pending or failed. For a status-check tool, that omission is a meaningful completeness gap.

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

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

Schema coverage is 100% and the single parameter is already documented as 'Render ID from create_video.' The description adds no further detail about the ID format, source, or reuse. Baseline 3 applies because the schema carries the parameter 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?

States a specific verb and resource: 'Check the status of a video render job.' An agent immediately knows this is a read-only status lookup. It stops short of naming siblings explicitly (e.g., create_video for producing the ID, retry_failed for failed renders), leaving differentiation to be inferred.

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

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

Usage is only implied: an agent must infer that this is polled after create_video, since the schema parameter mentions 'Render ID from create_video' but the description never says so. There is no guidance on polling cadence, when to stop polling, or what to do on failure versus success.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuine value beyond that by naming the returned fields (id, name, connectionCount, isDefault, connections) in the absence of an output schema, and by clarifying that connections are embedded in the response.

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

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

Three short sentences, front-loaded with purpose, followed by the domain concept and the return shape. Every sentence carries information an agent needs and there is no filler or repetition of the tool name.

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

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

For a zero-param, read-only listing tool with no output schema, the description covers purpose, concept, and return fields, which is close to everything needed to call it. It stops short of mentioning result ordering, pagination, or what an empty list means, which are minor for a small per-user collection.

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

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

The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly implies a global, unfiltered listing rather than a filtered one.

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 gives a specific verb and resource ('List account groups'), names the product, and gives concrete examples of groups plus their purpose (bundling social connections for targeting). It does not explicitly contrast with the singular sibling get_account_group, which is the only differentiation gap.

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

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

Usage is implied by the explanation that groups let you target multiple accounts in one create_post call, which hints at when to reach for this tool. There is no explicit when-to-use/when-not guidance and no pointer to get_account_group for single-group detail or create_account_group for setup.

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, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by describing what a returned kit contains and how its id feeds render_carousel, though it says nothing about ordering or result counts.

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

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

Two short sentences, front-loaded with what is listed and followed by the actionable integration hint. No filler or restatement of 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?

With no parameters and no output schema, the description carries the return-shape burden and does so by naming the four kit components, plus it closes the loop with the render_carousel consumer. Minor gaps remain (no indication of whether kits can be empty, ordered, or how many are returned), but nothing blocking.

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

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

The tool takes zero parameters, so the baseline is 4. The only id mentioned (brandKitId) belongs to render_carousel, not this schema, so there is no parameter meaning left unexplained.

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

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

States a specific verb (list) and resource (saved brand kits) and enumerates the contents of each kit (palette, font pairing, logo, handle), which distinguishes it cleanly from siblings like get_brand_voices and list_carousel_styles. An agent knows exactly what it will get back.

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 second sentence gives concrete downstream usage: take a kit's id and pass it as render_carousel's brandKitId for one-call branded output, effectively naming the follow-on tool. It does not state exclusions (e.g., when to prefer get_brand_voices instead), but the context 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds genuinely non-redundant behavior: it discloses the shape of what comes back (per-status counts, platforms, next scheduled time), which is valuable since there is no output schema. It does not mention pagination, result limits, or whether zero-post campaigns appear.

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, zero filler. The resource and returned fields are front-loaded, and the usage cue follows compactly. 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, no output schema, and annotations carrying the safety profile, the main burden is describing the return value, which the description does well. Minor gaps remain around result size, pagination, and whether campaigns with no posts are included.

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

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

The tool takes zero parameters and the schema is empty at 100% coverage, so there is nothing for the description to clarify. Baseline 4 applies; no parameter meaning is missing because none exist.

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

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

States a specific verb ('List') and resource ('campaign bundles'), and enumerates the returned data: campaign tags, post counts by status, platforms, next scheduled time. This makes it distinguishable from list_posts or list_media, though it never names a sibling to contrast with explicitly.

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

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

'Use this to see what a campaign contains before editing or deleting it' gives a clear trigger context for the tool. It stops short of naming alternatives or stating when not to use it (e.g. versus list_posts when you want individual posts rather than campaign rollups).

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

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

Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds that this is a reference catalog whose output is a set of ids meant to be fed into render_carousel, plus that palette colors come back resolved rather than as raw references. It does not describe response size or the static/account-agnostic nature of the catalog, which would have been useful.

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, front-loaded with the payload inventory and closed with the downstream action. The parenthetical qualifiers ('with content-variant layouts', 'with resolved colors') add real information rather than padding. The list is dense but each item maps to a return category, so nothing is wasted.

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

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

There is no output schema, so the description correctly takes on the burden of naming the returned categories: template families, palettes, formats, font pairings, slide caps. It does not state the top-level response shape or how large the catalog is (e.g. number of template families), which is the only remaining gap for a zero-parameter lookup 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 zero parameters there is no parameter semantics to explain, so the baseline of 4 applies. The description appropriately spends its space on what the tool returns instead of inventing arguments.

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?

Uses a specific verb ('List') against a named resource ('the carousel design system') and then enumerates its contents: template families, palette library with resolved colors, output formats, font pairings, slide caps. This is clearly distinguishable from siblings like generate_carousel, render_carousel, and get_carousel_render, which produce or fetch renders rather than catalog metadata.

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

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

'Use the ids with render_carousel' tells the agent where this tool fits in the workflow: call it first to obtain valid identifiers, then render. No explicit exclusions or 'when not to use' guidance is given, and it doesn't mention whether it should also precede generate_carousel, but the intended consumption path 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only the enumeration of platform types, which clarifies the scope of results but says nothing about ordering, pagination, or whether all workspaces are included.

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, front-loaded with the verb and resource, and the parenthetical examples earn their place by defining 'connections' for the agent. No redundant restatement of the title or annotations.

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 list tool with full annotation coverage and no output schema, the definition is nearly sufficient. The only missing piece is any hint about the shape or volume of the returned list, which is a minor gap for such a simple tool.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly signals that no filtering input is expected by saying it lists all connected accounts.

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 gives a specific verb ('List') and resource ('connected social media accounts') and clarifies what a connection is with examples (Instagram, Twitter, LinkedIn). It is clearly distinct from sibling tools such as list_account_groups or get_connection_link, though it never explicitly names those alternatives.

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

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

There is no when-to-use or when-not-to-use guidance, no mention of prerequisites, and no routing to related siblings like list_account_groups for grouped views. The agent must infer usage entirely from the tool name and the word 'List'.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds useful domain context by naming what a "content source" actually is (WordPress sites, RSS feeds) and its role (importing content for repurposing), which the annotations cannot convey. It says nothing about ordering or whether disconnected sources are included, so it falls short of 5.

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

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

A single sentence with the resource and its concrete instances front-loaded, and zero filler. Nothing in it could be removed without losing meaning.

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

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

For a zero-parameter, read-only list tool with rich annotations and no output schema, the definition supplies enough to invoke it correctly and understand what the list contains. A minor gap is the shape of the returned entries (names, types, IDs), which the description does not hint at and no output schema documents.

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

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

There are zero input parameters and 100% schema coverage, so parameter semantics carry no burden; the baseline of 4 applies. The description correctly implies a global listing with no filtering knobs, consistent with the empty schema.

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

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

The description uses a specific verb and resource ("List connected content sources") and disambiguates with parenthetical examples ("WordPress sites, RSS feeds") plus the reason they exist ("used to import content for repurposing"). An agent can distinguish this from siblings like list_connections or list_imported_content, though it never explicitly names those alternatives.

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

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

Usage is only implied: listing content sources is self-evidently a discovery/read step that would typically precede add_content_source, fetch_source_content, or repurpose_content, but the description never says so. No when-not-to-use or alternative routing is provided, leaving the agent to infer the workflow position 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered without help. The description adds no behavioral detail beyond them — nothing on pagination, ordering, or what happens with an unknown source id — so it contributes only marginally.

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

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

One sentence, front-loaded with the action and resource, with a trailing clause that earns its place by naming concrete consumer tools. No redundant restatement of 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?

For a one-parameter read tool with rich annotations this is close to sufficient, but there is no output schema, so the description should hint at what is actually returned (item ids, titles, counts) to let an agent chain it into repurpose_content confidently. That gap keeps it at minimum-viable completeness.

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%: the single parameter 'id' is documented as 'Content source ID', which matches what the description says about listing from a source. The description adds no format, example, or constraint information beyond the schema, so baseline 3 applies.

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

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

States a specific verb (list) plus a scoped resource (content already imported from a source), which separates it from list_content_sources and fetch_source_content by implying retrieval of already-ingested items rather than sources or raw fetches. It stops short of naming those siblings explicitly.

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

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

The description gives downstream context by naming repurpose_content and create_post as consumers of the output, which helps an agent place the tool in a workflow. It does not say when to use this instead of fetch_source_content or list_content_sources, so preference between siblings is left to inference.

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

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

Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false). The description adds useful behavioral detail about the return shape and its interoperability with create_post's media array, but says nothing about ordering or pagination beyond what the schema's defaults state.

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

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

Two sentences, front-loaded with resource and purpose, followed by the payoff detail. Nothing is repeated from the name or title and there is 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?

No output schema exists, so the description must explain the return value — it does so at exactly the useful level by tying results to create_post's media array. Pagination mechanics and total counts are left implicit, which is a minor gap given the schema's documented defaults.

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

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

Schema description coverage is 100%, so page, limit, type and search are already well documented with defaults and max. The description adds meaning the schema cannot: the returned items are already shaped for create_post's media array, an interface-level contract that materially affects how the agent uses filters and results.

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

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

States a specific verb and resource (list the media library already uploaded) and adds the reuse intent, which distinguishes it from the sibling upload_media by framing this as the reuse path.

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

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

Gives a concrete context — reuse an asset instead of uploading it again — which implicitly steers agents away from upload_media when the asset exists. It does not name the alternative explicitly or state when-not-to-use, but the guidance is specific enough to act on.

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, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds that non-pending outcomes are returned too, which is genuinely useful. It says nothing about result volume, ordering, or pagination, which is a meaningful gap for a list tool.

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

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

Two short sentences, no filler, with the filtering hint front-loaded after the core action. The parenthetical '(and their outcomes)' is slightly in tension with 'waiting for approval', but it is efficient overall.

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-optional-parameter read tool with full annotation coverage and no output schema, the definition is close to sufficient. It still omits what a returned record contains and whether results are bounded, which an agent would want before calling it to assemble a review queue.

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 enum-like values plus the 'Default: all' behavior are fully documented in the schema itself. The description repeats the filtering idea without adding format or combination guidance beyond the schema, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource ('List posts waiting for approval') plus the added scope that outcomes are included, which an agent can act on directly. It does not explicitly distinguish itself from close siblings like list_posts or get_approval_status, so it stops short of a 5.

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

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

'Filter by status to build a review queue' implies the intended workflow, so usage is more than absent. However, it never names when to prefer list_posts (all content) or get_approval_status (single item) instead, leaving sibling routing to inference.

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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that: no pagination behavior, no mention that results are paged with a default page size, and no hint about what is returned per post. Credit is limited to the filter-scope statement.

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, front-loaded with the resource and immediately followed by the filter surface. Every clause earns its place 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 9-parameter read tool with no output schema, the definition is adequate on inputs but silent on result shape, pagination defaults and ordering when no sort is given. It is minimum viable rather than complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description names the same filter axes the schema documents (status, platform, campaign, label, post type, free text) but adds no format, matching semantics or constraints 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 verb and resource ('List ... social media posts') and enumerates the filter dimensions, which cleanly separates it from get_post (single item) and list_pending_approvals. The phrase 'scheduled and published' is slightly narrower than the actual status enum, which also covers draft, failed and cancelled, but the intent is still unmistakable.

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 list of filter axes implies when this tool is appropriate, but there is no explicit guidance on when to prefer it over siblings such as list_pending_approvals, get_analytics or list_campaigns, and no exclusions. Usage is inferable rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds workflow context beyond that: templates expose editable fields that feed create_video, which tells the agent what to do with the result. It omits pagination/ordering behavior, keeping it from a 5.

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

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

Two tight sentences, with the resource and its categories front-loaded and the downstream action second. No redundant restatement of the tool name or filler 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 single optional-filter list tool with full annotation coverage and no output schema, the description supplies enough: what is listed, what each item contains, and what to do next. It could say whether results are ordered or filtered by default, but no agent-critical detail 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 single `category` parameter is fully described in the schema (100% coverage), so the schema carries the load. The description never mentions filtering by category, though the parenthetical category names loosely hint at valid values; baseline 3 applies.

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

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

States a specific verb and resource ("List available video templates") and enumerates the concrete categories returned (quotes, hooks, listicles, stories, product showcases, testimonials, promos). That enumeration clearly separates it from sibling listers such as list_carousel_styles or list_media without needing the schema.

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

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

The clause "use them with create_video" gives an explicit downstream use and implies this is a discovery step before video creation. It does not state when-not to use it or compare against the other template/style listers, so it stops short of full routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description still adds real value beyond that: it discloses the return payload's contents and, importantly, rules out an expectation an agent would plausibly have — it does not return screenshots, only structured data plus a dashboard link. It does not discuss permissions or freshness/caching of the preview, which keeps it from a 5.

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

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

Three sentences, front-loaded with the core behavior, then the when-to-use trigger, then the return-format caveat. No filler and no repetition of the schema or annotations.

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

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

With no output schema, the description takes on the job of explaining what comes back, and it does: platform-resolved body, media, character counts, link behavior, warnings, plus a dashboard link and the explicit absence of screenshots. For a single-parameter read-only 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?

There is a single parameter (id) with 100% schema description coverage ('Post ID to preview'), so the schema carries the meaning. The description says nothing additional about the id — e.g. whether draft, scheduled and published posts are all valid inputs — 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?

States a specific verb and resource: shows exactly what each platform will receive for a post, and enumerates the resolution it performs (body after platformContent overrides, attachments after platformMedia overrides, character count vs limit, link clickability, warnings). This clearly separates it from siblings like get_post or list_posts, which return stored data rather than platform-resolved previews.

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 says to use it BEFORE scheduling or publishing and calls out the high-risk cases (carousels, videos, multi-platform posts). It stops short of naming the alternative tool to use instead for other needs, or stating when a preview is unnecessary, but the timing guidance 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?

Beyond the annotations, the description discloses that the post is sent to all connected platforms and adds a critical X-specific constraint: links are rejected in posts, thread segments, and first comments. The billing explanation and the platformContent.twitter workaround give useful behavioral context that an agent could not infer from the annotations alone.

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 action and then moves to the important X constraint. It is mostly efficient, though the billing detail is somewhat verbose and the platformContent.twitter instruction is not actionable through the listed 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 simple one-parameter publish tool with rich annotations, the description covers the main purpose and a significant platform-specific restriction. The remaining gap is that it references platformContent.twitter without explaining how an agent should set that content when the tool only accepts an id.

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 only one parameter, id, and its description already covers its meaning at 100% schema coverage. The description does not add further meaning to id, and its reference to platformContent.twitter does not correspond to any input parameter, so it does not improve parameter clarity.

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: publishing a draft or scheduled post immediately to all connected platforms. This clearly distinguishes the action from create_post or update_post by focusing on immediate publication of an existing 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?

It gives clear usage context: use this when a draft or scheduled post should go out immediately. It does not explicitly name alternatives such as update_post or preview_post, nor does it state when not to use this tool, so it falls short of full when/when-not 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 destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is known from structured data. The description adds nothing beyond the title: it does not say whether removed connections are deleted or merely unassigned, what happens to IDs not present in the group, or whether the call is atomic or partial-failure. For a destructive operation, that is a meaningful gap.

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

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

A single front-loaded sentence with no filler. It is efficient, though its brevity is partly the cause of the missing behavioral detail rather than a sign of disciplined editing.

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

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

This is a destructive, non-idempotent bulk mutation with two required parameters and no output schema, so the description should carry more of the behavioral load. It does not explain the result of a partial match, error behavior, or what the caller gets back, leaving an agent to guess at the outcome of an irreversible-seeming write.

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 both parameters (id as Group ID, connectionIds as the IDs to remove) are described in the schema itself. The description adds no extra meaning such as whether connectionIds can include IDs outside the group or whether the list is order-sensitive, so the baseline 3 applies.

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

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

A specific verb (remove) and resource (social connections from an account group) make the operation unambiguous, and it is naturally distinguishable from the sibling add_connections_to_group. It does not explicitly name that sibling or any other alternative, so it falls short of the 5 bar.

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

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

There is no guidance on when to use this versus add_connections_to_group, delete_account_group, or list_connections, and no stated preconditions. The only implied usage comes from the verb itself and the group-oriented siblings.

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

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

Annotations only declare the generic write profile (readOnly=false, destructive=false, idempotent=false, openWorld=false). The description adds genuinely new behavior: rendering happens server-side, produces persistent media-library assets, and returns an ID rather than the images, so the caller must poll. It does not address what a re-render does to prior output or whether repeated identical calls duplicate media, which matters given idempotentHint=false.

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

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

Three sentences, front-loaded with the action and artifact, then the async contract, then layout rules. No filler and no restatement of 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?

For a 14-parameter, nested-object, async tool with no output schema, the description covers the essentials an agent needs: what is produced, where it lands, and how to retrieve the result. It could go slightly further on render failure behavior or how the returned ID is used beyond polling, but nothing critical 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 baseline is 3, but the description adds layout semantics not implied by the schema: slide 1 takes the cover layout, the last slide the CTA layout, and middle slides cycle content variants. That helps an agent reason about ordering and length. There is mild tension with the schema's claim that the 'type' enum pins cover/CTA, but not a hard conflict.

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?

"Render carousel slides into branded PNG images (server-side, pixel-perfect) saved to the media library" gives a specific verb (render), a specific resource (carousel slides), the output artifact (PNG in media library), and distinguishes it from siblings like generate_carousel or preview_post. The follow-up instruction to poll get_carousel_render names the related tool explicitly.

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

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

It states the post-call workflow clearly (poll get_carousel_render until 'completed'), which is the main usage hazard for an async render. It also signals the input can come from generate_carousel via the schema, but the description itself never says when to use this versus generate_carousel or preview_post, and gives no 'when not to use' boundary.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=false, so the mutation profile is covered. The description adds one genuinely useful behavioral fact beyond that: output lands as drafts, not live posts. It says nothing about what happens with invalid connectionIds, whether duplicates are created (consistent with idempotentHint=false), or what is returned.

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

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

Two short sentences with the key action front-loaded and no filler. The second sentence is close to redundant with the schema, which keeps it from a 5.

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 write tool with full schema coverage the description covers the essentials, but with no output schema it should say what saving actually yields (created draft IDs, per-post success/failure) and whether connections must be pre-validated. Those omissions matter for a mutation 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% for the single nested posts parameter, and the schema already documents content and connectionIds. The description merely echoes "content and target connections" without adding format, limits, or ordering 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?

"Save AI-repurposed content as draft posts" gives a concrete verb (save) and resource (draft posts) with a meaningful qualifier that the result is a draft rather than a published post. It does not, however, distinguish itself from siblings like create_post or bulk_create_posts, so an agent must infer the boundary.

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

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

The second sentence only restates the input shape (array of posts with content and target connections) rather than saying when this tool should be chosen. There is no mention of bulk_create_posts or create_post as alternatives, and no guidance on when repurposing is appropriate versus direct creation.

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, idempotentHint=false and openWorldHint=true, but the description goes further by defining the blast radius: already-published platforms are never re-posted, non-transient failures are refused rather than retried, and refusals come back with their fix. That converts a scary destructive flag into a predictable, scoped mutation.

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

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

Four sentences, all load-bearing, with the core action front-loaded before the eligibility rules and the prerequisite check. The long parenthetical enumerations of failure causes are the only place density tips toward clutter.

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

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

No output schema exists, and the description covers the refusal path (returned with their fix) but not the success return shape — whether it reports which platforms were re-queued or what the post status becomes. For a single-parameter tool this is nearly complete, with that one return-side 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?

There is a single required parameter at 100% schema coverage, and the schema already states it must be a post with status failed or partially_published. The description adds only the tie-in to get_post's platformResults, which is guidance rather than new meaning for the id itself, so baseline 3 applies.

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

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

States a specific verb (retry) and a precisely bounded resource (platforms that failed on a post with status failed or partially_published). The scope qualifier alone separates it from publish_post and update_post, so an agent can pick it without opening any schema.

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

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

Explicitly routes the agent through a prerequisite step (check get_post → platformResults[].errorClass / .fix first) and spells out the acceptance condition: only transient classifications (outage, rate limit, network) are re-queued. It also names the exclusion cases (account reconnect, X API credits, TikTok visibility, payload-caused failures) so the agent knows when this call will be refused.

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 flag destructiveHint=true and idempotentHint=false, and the description goes further by disclosing replace-not-merge semantics, the Pro-tier gating, the required schedule:write permission, and the inheritance side effect of an empty group array. That is exactly the extra context annotations cannot convey.

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

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

Three short sentences, front-loaded with the mutation and its replace semantics, each carrying distinct information with no repetition of the schema or annotations.

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 bulk-replace tool this covers scope, prerequisites, and the empty-array edge case. It stops short of saying what happens to already-queued or scheduled posts whose slots are removed, which is the one behavior an agent might still need.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: slots must be the complete list, and an empty array plus groupId has a specific inheritance effect, while omitting groupId targets the global schedule.

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

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

States a specific verb and resource ('Replace the weekly posting queue slots') plus scope ('global schedule or one account group'), which cleanly separates it from read-oriented siblings like get_posting_schedule and suggest_schedule.

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?

Explains the call contract clearly: pass the FULL desired list because it replaces the existing one, and an empty array on a group removes the override. It does not explicitly tell the agent to read the current schedule first via get_posting_schedule, so there is a minor gap in when-to-use routing.

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 declare the generic mutation profile (not read-only, not destructive, not idempotent), so the description adds real value: it discloses the returned approve link and approval ID, and the important downstream side effect that an approved post auto-schedules when it has a scheduledFor time. It stops short of covering permission/auth requirements or what happens on expiry beyond the schema's expiresInDays note.

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: purpose first, usage condition second, return and side-effect behavior third. Every sentence contributes new information and there is 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 four-parameter mutation with no output schema, the description covers purpose, trigger conditions, return payload, and the post-approval scheduling behavior, which is enough to call it correctly. Minor gap: it does not mention the sibling get_approval_status that a caller would use to poll the returned approval ID.

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

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

Schema description coverage is 100%, so all four parameters (postId, supersede, expiresInDays, reviewerEmail) are already well documented, including the 409 default behavior. The description adds no parameter-level meaning beyond referencing scheduledFor, which is a post field, not an input here. Baseline 3 applies when the schema carries the parameter burden.

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

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

States a specific verb and resource ("Submit a post for human approval") with a qualifier that separates it from a plain publish. It does not explicitly name publish_post or create_post as the alternatives, so the distinction is implied rather than stated.

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

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

Gives two explicit triggering conditions: the API key requires approval, or the caller wants a human sign-off before publishing. That is clear when-to-use guidance, but it never says when to skip this tool and call publish_post directly, nor does it point to get_approval_status for polling.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so safety is covered. The description adds the substantive behavioral fact that an internal 'smart scheduler' picks optimal times rather than the caller specifying them, but says nothing about determinism, tenant/account scoping, or how many timestamps come back.

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

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

Two short sentences with zero filler. The core action is front-loaded and the downstream consumer is noted in the second sentence where it is most useful.

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

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

With no output schema, the description does supply the essential return contract: concrete timestamps intended for create_post. What is missing is return cardinality and shape (one timestamp per post, ordered?) and any note on platform influence, but for a four-parameter read-only planning tool it is close to 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?

Schema coverage is 100%, so all four parameters are already documented with formats and examples. The description only restates 'N posts' and 'date range' in prose, adding no format, constraint, or interaction detail beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource: spread N posts across a date range at optimal times, returning concrete timestamps. It also distinguishes itself from the write path by naming create_post as the consumer of its output, so an agent can tell it apart from siblings like get_best_times or bulk_create_posts without opening a schema.

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

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

The handoff to create_post implies this is a planning step that precedes actual scheduling, giving implied usage. However, it never says when to prefer this over get_best_times or get_posting_schedule, nor any exclusions or prerequisites, so the agent must infer the choice among similar siblings.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false; the description corroborates destructiveness by saying the connection list is replaced wholesale. It adds nothing about partial-update behavior for omitted fields, permission requirements, or consequences of an invalid connectionIds array — meaningful gaps for a destructive mutation.

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

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

One sentence, front-loaded with the verb and resource, followed by the affected fields. No filler and no repetition of the tool name.

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 six-parameter destructive mutation with no output schema, the description covers what can be changed but not how the call behaves: whether omitted fields are left untouched, what an empty connectionIds list does, or what failure modes exist. Adequate but with clear gaps an agent would want filled.

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 only 33% (name, color, isDefault, description carry no schema descriptions), so the description's enumeration of those fields genuinely compensates. It also reinforces that connectionIds is a full replacement rather than an append, though the schema already states REPLACES, and the required id parameter is left unexplained.

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 gives a specific verb (update) and resource (account group) and enumerates the editable fields, so the agent knows exactly what can change. It hints at replacement semantics for connections but never names the closely related siblings add_connections_to_group or remove_connections_from_group, so the differentiation is only partial.

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

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

Usage is implied by the field list and the phrase 'replace its full connection list,' which signals when to prefer this over incremental add/remove tools. However, no explicit when-to-use or when-not-to-use guidance is given, and the agent must infer the alternative 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?

Adds substantive behavior not in annotations or schema: the X API rejects any post/thread/comment containing a link, with the billing reason ($0.20 vs $0.015) and the workaround (link-free version in platformContent.twitter). Annotations already flag destructive/openWorld, so the bar is lower, but the description omits that media arrays are replaced wholesale and that partial failures are possible.

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

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

Purpose is front-loaded in one short sentence, followed by the X-constraint block. The billing rationale is slightly verbose but earns its place by explaining why the constraint exists rather than just asserting it.

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 15-parameter destructive mutation with no output schema, the description covers only the X-link gotcha and the publish routing. It says nothing about how replacement semantics affect existing media/overrides, what the response returns, or how validation failures surface — those rely entirely on schema descriptions.

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

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

Schema coverage is 100%, so baseline is 3; the description adds real meaning on top by naming platformContent.twitter as the link-free escape hatch and by clarifying that schedule rejects 'now'. It says nothing extra about media replacement, utm, or connectionIds beyond the schema text.

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

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

States a specific verb and resource ('Update a draft or scheduled post'), which also scopes what kinds of posts are editable. It does not explicitly distinguish from siblings like preview_post or create_post, though the publish_post hand-off gives implicit separation.

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 names the alternative for the immediate-publish case ('Use publish_post to publish immediately — now is rejected here'), which prevents a common misfire. Lacks guidance on when to use this versus create_post or preview_post, so usage is clear but not fully bounded.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds the media-type scope but omits behaviour an agent needs: that the returned URL must be PUT to, that it expires, and whether a media record is reserved server-side. No contradiction with annotations, but limited added value.

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

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

A single well-formed sentence with the action front-loaded and zero filler. It is arguably too terse for a multi-step upload flow, but nothing is redundant.

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

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

There is no output schema, so the description carries the burden of explaining the return value — a presigned URL plus any upload key/media identifier — and it does not. For a tool whose whole purpose is producing a URL the agent must then use, that is a 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?

Schema description coverage is 100%, so filename, contentType and size are already documented with examples; baseline is 3. The description only narrows contentType to image/video and does not add constraints such as size limits or supported MIME types.

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

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

States a specific verb+resource: 'Get a presigned URL to upload an image or video'. That distinguishes it from list_media and generate_image, but it does not name or explicitly differentiate against those siblings, so it stops short of a 5.

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

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

'for use in posts' implies the upstream position in the create_post workflow, but the description never states when to use this versus generate_image or list_media, nor any prerequisite (account/connection) or when-not condition. Usage is implied rather than guided.

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