Broadcast

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

Annotations already flag destructiveHint=true and idempotentHint=false, but the description adds materially: irreversibility ('cannot be undone'), that media is destroyed alongside the post, that published posts are only removed from Broadcast and not from external networks, and that the delete scope is required. That is exactly the kind of consequence detail an agent needs before a destructive 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?

Three dense sentences: destruction/irreversibility first, then routing to the alternative, then the published-post caveat and scope requirement. No filler, correctly front-loaded.

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

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

For a one-parameter destructive tool with no output schema, the description covers consequences, permissions, and the network-vs-Broadcast distinction. Nothing an agent needs to call it safely is missing.

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

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

With a single parameter at 100% schema description coverage, the schema already explains that id comes from get_schedule or schedule_post. The description adds no further parameter meaning, 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 opens with a specific verb and resource ('Permanently deletes a post and its media') and immediately distinguishes itself from update_post, the sibling that handles text/date changes. An agent can route between the two without inspecting schemas.

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 triggering condition ('Only use it when the user asks to drop a post') and names the explicit alternative with its selecting condition ('to change the text or date, use update_post instead'). Nothing 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?

With annotations supplying only generic safety flags, the description carries substantial extra weight: it discloses the 15-minute polling cadence, the fact that existing articles are skipped (non-backfill semantics), the approval-queue default, the publish-scope requirement for autoPublish, the 10-feed cap, and the TikTok limitation. These are exactly the behaviors an agent needs that the annotations cannot express.

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 action, then consequences, then constraints. Every clause carries information — no filler, no restatement of the 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?

No output schema exists, but the description covers the full lifecycle of calling this tool: what gets followed, what happens to existing vs new content, cadence, approval behavior, scope requirement, target limitations, and a quantity cap. Nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3; the description still adds value by stating the autoPublish policy condition ('only when the user asked for it'), reinforcing the accounts-vs-platforms alternative, and repeating the TikTok restriction tied to the accounts parameter. It does not add syntax or format detail beyond the schema, so it sits just above baseline.

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

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

States a specific verb and resource ('Follows an RSS or Atom feed') and immediately clarifies the resource boundary (a blog address is accepted and its advertised feed resolved). This cleanly separates it from siblings like unfollow_feed, update_feed, and list_feeds.

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 concrete operational context — today's articles are skipped, future ones become posts, checked every 15 minutes — plus an explicit exclusion ('TikTok cannot be a target') and a policy gate for autoPublish ('only when the user asked for it'). It stops short of naming sibling tools (e.g. update_feed for changing an existing follow), so it is not a full when/when-not routing guide.

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), so the bar is lower; the description adds real value by disclosing what the response contains per network — status, published link, network error, and stats that are null until read. It stops short of noting not-found behavior or rate limits, 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?

Purpose is front-loaded in the first clause, followed by return detail and then the routing sentence. The dense parenthetical on stats semantics is justified because there is no output schema, though it slightly burdens a single 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?

With no output schema, the description carries the return-value burden, and it does so by enumerating status, link, error, and stats fields. An agent has enough to call and interpret it; only failure/not-found handling is 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?

Only one parameter and schema coverage is 100%, so the schema already documents the id fully (including that it comes from schedule_post or get_schedule). The description repeats 'by id' without adding format or edge-case semantics, 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 ('Returns one post by id') and immediately scopes it as per-network results, which separates it from list-style siblings. The contrast with get_schedule makes the distinction unambiguous even 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?

Gives explicit triggers ('after publishing', 'when get_schedule shows a post as partial or failed') and names the alternative with its own condition ('use get_schedule instead to browse several posts'). This is a full when/when-not/alternative triad.

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 burden is lower. The description still adds real behavior: results are sorted by date when a range is given, the default cap is 50 posts, and per-network results are deliberately omitted. It does not discuss pagination beyond the limit or response shape, so it stops short of a 5.

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

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

Three sentences, each earning its place: what it returns, how to filter, and how to route around it. The defaults and the schedule_post workflow rule are front-loaded 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 read-only listing tool with no output schema, the description supplies everything an agent needs: filter modes, default limit, ordering, and sibling routing to get_post for per-post details. Safety is already covered by annotations.

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, but the description adds value the schema does not: date-range reads are sorted by date, an empty argument set defaults to the 50 most recent, and status filtering is the third mode. It does not spell out the enum values beyond what the schema lists.

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 ('Lists') and resource ('posts') plus what each row contains (status, date, targets). It is clearly distinct from get_post, which it explicitly names as the per-post alternative.

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

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

Gives explicit invocation modes (from/to range, status filter, or nothing for the 50 most recent), a workflow rule ('read before schedule_post to avoid duplicates and slots too close together'), and an exclusion routing to get_post. When and when-not are both covered.

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 read-only/idempotent annotations, the description discloses data provenance (Bluesky, Facebook, Instagram; views included), the measurement window ('read for 30 days after publication'), and negative coverage (X, LinkedIn, TikTok return available: false). These are exactly the behavioral traits annotations cannot express and that change how an agent interprets results.

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

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

Front-loaded with the core capability, then usage, then data caveats — a logical order with no filler. The sentences are long and clause-dense (three semicolon-separated segments in one block), which slightly hurts scanability, but every clause carries information.

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

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

There is no output schema, so the description must convey the return shape, and it does: totals, per-network counts with follower change, interactions per publication day, and best posts. Combined with the availability caveats, an agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 100%, so 'from', 'to' and 'top' are already fully documented with types and defaults, making 3 the baseline. The description corroborates the period semantics and that 'the best posts' are a returned artifact, but adds no syntax, format or default detail beyond the schema.

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

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

States a specific verb and resource ('Returns how published posts did over a period') plus the analysis scope: totals, per-network metrics, per-day interactions and best posts. It explicitly contrasts with the sibling get_post for single-post numbers, so an agent can route correctly 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?

Gives concrete triggering conditions ('when the user asks what worked, which network or which post performed best, or to pick the next posts' topics and times') and names the alternative tool (get_post) with the case that selects it. It also states an explicit usage restriction: never compare X, LinkedIn or TikTok on these numbers because they are not read.

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, so the safety profile is covered. The description adds genuine context beyond that: the ids are the targeting keys for downstream tools and missing entries represent an unconnectable network, which shapes how an agent should react to the result. It stops short of describing return ordering or result size, keeping it at a 4.

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

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

Two sentences with no filler. The output shape comes first, then the imperative workflow instruction, so the most actionable guidance 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?

With no parameters, no output schema, and annotations already carrying the safety profile, the description supplies the remaining missing pieces: the return fields and the downstream dependency on the returned ids. Nothing an agent needs in order to call this correctly is absent.

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

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

The tool takes zero parameters, so the baseline is 4 and there is no schema-level argument meaning to add. The description helpfully compensates for the absent output schema by naming the three fields each account record carries.

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 ('Lists the social accounts connected to Broadcast') and even enumerates the returned fields (id, platform, handle), so an agent knows exactly what it gets back. It is clearly distinguishable from siblings like get_post or list_feeds, which operate on different resources.

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 'Call it first' and names the three dependent tools (schedule_post, validate_post, update_post) that consume the returned ids. It also states the negative condition: a network absent from this list cannot be posted to until the user connects it, which is exactly the when/when-not guidance an agent 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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description goes beyond that by disclosing the return shape (id, address, target accounts, autoPublish flag, last read error) and the autoPublish semantics, which is meaningful context not present in structured fields.

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

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

Three sentences, front-loaded with the resource and behavior, then the return fields, then the routing guidance. Slightly dense with parentheticals, but each sentence carries distinct load and nothing is wasted.

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

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

With no output schema and no parameters, the description must explain what comes back — and it does, listing every returned field and its meaning. Combined with the sibling-routing guidance, an agent has everything needed to call this 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 takes zero parameters, so the baseline is 4. There is nothing to disambiguate and the description correctly omits parameter detail rather than inventing any.

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 ('Lists') and resource ('RSS or Atom feeds Broadcast follows'), and further clarifies the causal model — each new article becomes a post for the feed's accounts. An agent can distinguish this from follow_feed/unfollow_feed/update_feed 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 names the downstream consumers and conditions: 'Call it to get the id that update_feed and unfollow_feed take, or before follow_feed to avoid following the same feed twice.' This states both when to call it and the concrete alternatives it feeds into.

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

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

Annotations only say it is a non-read-only, non-destructive write; the description adds far more: the approval gate for 'review', credit checks for X, the propagation of recurring posts, the idempotency-key retry behavior, and the failure mode where a failed firstComment leaves the post published with errors reported. No contradiction with annotations — idempotentHint=false is consistent with the guidance to supply a key manually.

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 correctly: the status/review-vs-scheduled decision and sibling routing come first, reference material (network limits) comes last. It is long, and the character-count table partly duplicates what validate_post can return, but each line is informative rather than 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 12-parameter mutation tool with nested objects and no output schema, the description covers the return shape ('Returns the post, or the validation errors when a network rule is broken'), the timezone/format convention for dates, and the per-network constraints. Nothing essential for a correct call is missing.

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

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

Schema description coverage is already 100%, so the schema carries parameter documentation (baseline 3). The description still adds cross-parameter semantics the schema does not state: status interacts with scheduledAt ('review' default when scheduledAt is set), 'now' means publish within a minute, repeat creates the next occurrence on each send, and overrides is meant for per-network shortening.

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+resource ('Creates a new post for one or more networks') and immediately names the sibling it is not ('to change a post that already exists, use update_post instead'). An agent can distinguish it from update_post, get_post and validate_post 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?

Explicit routing: use update_post for existing posts; use 'scheduled' only when the user explicitly asked to publish without approval, otherwise keep 'review'. It also states a hard limitation (TikTok cannot be scheduled from the API; use review) and a mandatory convention ('Always pass an idempotencyKey').

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?

Goes well beyond the annotations by disclosing what persists after the operation (existing posts and scheduled ones remain) and what does not (no new posts), plus the required authorization ('Requires the delete scope'). The destructiveHint=true annotation is consistent and reinforced with concrete consequences.

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

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

Three short sentences, no filler: effect first, then retention/cancel guidance, then the alternative tool, then the permission requirement. Every clause earns its place.

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

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

For a one-parameter mutation with no output schema, the description covers the state change, retained side effects, escape hatches, and auth scope. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% for the single 'id' parameter, and the schema already documents that the id comes from list_feeds. The description adds no format or sourcing detail 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?

States a specific verb+resource ('Stops following a feed') and immediately defines the resulting behavior ('no new post is made from its articles'). It distinguishes itself from update_feed and cancel_post by name, so an agent can separate it from siblings without opening schemas.

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: use cancel_post to remove already-scheduled posts, and use update_feed if the goal is only changing accounts or approval settings. Both alternatives and the conditions that select them are given.

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

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

Adds real behavioral context beyond the annotations: partial-update semantics ('Only the fields given change'), non-retroactivity ('posts already made from the feed are not touched'), and an auth requirement (autoPublish 'needs the publish scope'). The destructiveHint=false and readOnlyHint=false annotations are consistent with this account of a scoped mutation. It does not describe failure modes or the response, keeping it short of a 5.

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

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

Three tight sentences with the purpose front-loaded and the alternative-routing advice last, so the reader gets the operation before the rationale. The parenthetical 'autoPublish, publish scope; only when the user asked for it' is telegraphic but not padding.

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

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

For a 4-parameter mutation with no output schema and annotations already covering the safety profile, the description supplies purpose, partial-update semantics, auth scope, and alternative routing. Only return/error expectations are unstated, which is a minor gap.

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

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

Schema description coverage is 100%, so id, accounts, platforms, and autoPublish are already fully documented, including the accounts-vs-platforms relationship and the TikTok restriction. The description only reinforces autoPublish and adds the 'only when the user asked for it' policy note, 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 (changes) and resource (a feed already followed), and enumerates the two mutable facets: target accounts and autoPublish behavior. It is clearly distinguishable from follow_feed/unfollow_feed because it operates on an existing feed and explicitly positions itself as the in-place alternative to those two.

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: 'Use it instead of unfollowing and following again, which would skip the articles already listed in the feed' names the sibling path and the condition selecting this tool. It also adds a policy gate for autoPublish ('only when the user asked for it'), which is a when-to-use constraint rather than a when-not.

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 the safety profile (not read-only, not destructive, not idempotent), but the description adds real behavioral context they don't carry: partial-update semantics ("Only the fields given are changed"), the immutability of already-published posts, and the elevated authorization required to auto-publish. It stops short of describing response shape or failure modes, but that is a minor gap for a tool whose annotations already cover mutation risk.

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

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

Four tight sentences, front-loaded with what gets edited and immediately followed by the routing decision and the caveats. No sentence is filler; each adds either scope, an alternative, or a constraint.

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 12-parameter mutation tool with nested media/overrides objects and no output schema, the description covers the essentials an agent needs: what changes, that updates are partial, the two sibling routes, and the publish-scope gate. It does not say what the call returns or how validation failures surface, though the schema's firstComment text partially covers the latter.

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 12 parameters in detail (including repeat, overrides, firstComment limits and scheduledAt formats). The description only gestures at the same field list and adds no syntax, format or default information beyond it. 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?

Opens with a specific verb and resource ("Edits a draft, review or scheduled post") and enumerates the mutable field families, so the agent knows exactly what surface this tool covers. It also draws the boundary against schedule_post and cancel_post by name, making it distinguishable from siblings 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?

Gives explicit alternatives and the condition that selects each: use this instead of schedule_post to fix or reschedule without creating a duplicate, and instead of cancel_post when the post should still go out. It also states a when-not (published posts cannot be edited) and a precondition (status "scheduled" needs the publish scope and should only be used when the user asked).

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

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

With annotations covering the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description adds real operational context: input constraints, the returned key, and the downstream dependency chain. It does not clarify idempotency behavior (whether re-uploading the same URL duplicates media) or any auth requirements. Minor tension: it fetches arbitrary public URLs while annotations declare openWorldHint=false, though this reads more as an annotation imprecision than a description error.

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

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

Three tight sentences, front-loaded with the core action and return value, then workflow placement, then network-specific requirement. Every clause carries information; none 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?

No output schema exists, and the description supplies the one return value an agent needs (`key`). Combined with the explicit placement in the post workflow and the media-vs-URL distinction, an agent has everything required 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?

Schema description coverage is 100%, so both `url` and `alt` are already fully documented structurally. The description restates the format/size constraints already present in the schema and says nothing about `alt` semantics, so it adds little 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?

States a specific verb (copies) and resource (public image/video into Broadcast), names the accepted formats and size caps, and explicitly identifies the returned artifact (`key`). It is immediately distinguishable from sibling write tools like schedule_post and update_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?

Explicit ordering instruction ('Call it before schedule_post or update_post whenever the post has media'), an exclusion ('a plain URL is not accepted there'), and a required-case note for Instagram/TikTok. This is a model example of when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint/idempotentHint/non-destructive, but the description goes further with behavior the annotations cannot express: no side effect, the exact per-network rules the server enforces (characters, link counting, media type/count/size, clickability, scheduling restrictions for TikTok), and the credit cost of firstComment on X. This is real operational context, not restatement.

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 routing sentence is perfectly front-loaded and the network rule list is dense with decision-relevant facts rather than filler. However, the closing firstComment paragraph and the date/time-zone note largely restate schema descriptions and scheduling semantics that a read-only validation call does not obviously need.

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 12 parameters, no output schema and nested media objects, the description covers the two things that matter most: the per-network constraints that produce errors and a sketch of the return payload (errors, warnings, rendered text). It leaves open what validation does with the scheduling-oriented fields (repeat, scheduledAt, status, idempotencyKey) that the schema still exposes.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description adds semantics the schema cannot: the per-network character ceilings and link-count rules that determine whether `body` is valid, and the guidance to use `overrides` for a shorter text on one network. It stops short of explaining how repeat/scheduledAt/status/idempotencyKey interact with validation.

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+resource+scope: 'Checks a post against every target network without creating anything', then enumerates exactly what comes back (errors, warnings, per-network text with length). The contrast with schedule_post in the same sentence lets an agent distinguish the two siblings without opening either schema.

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

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

Explicitly states when to use it ('Call it before schedule_post when unsure whether a text, link or media fits every network') and names the alternative plus its consequence ('schedule_post runs the same checks and refuses an invalid post'). It also gives the reason to prefer validation ('lets you fix it first with no side effect').

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