Breakreach

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

Adds significant behavioral context beyond annotations: the 7-day private reply limit, one DM per person per rule, and the distinction between private and public replies. Annotations only give safety hints (readOnly=false, destructive=false), so this description carries the burden well. It could mention rate limits or permission requirements but covers the core mechanics.

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

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

The description is front-loaded with the core purpose and then flows into mechanics and targeting. It's a single dense paragraph but well-structured; every sentence earns its place by explaining behavior or targeting. Could be slightly tighter but no wasted words.

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

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

Covers the trigger, action, network-specific behavior, and targeting parameters. With no output schema, the description doesn't explain return values, but for a creation tool that's often acceptable. It omits error handling or prerequisites like account connection status, but overall provides enough context for correct invocation.

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

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

Schema coverage is 100%, so the schema already documents all parameters thoroughly. The description hints at targeting via mediaId/postId but doesn't add syntax or format details beyond what's in the schema. 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?

States a specific verb (Set up) and resource (Comment to DM automation), and clearly distinguishes itself from siblings like create_dm_automation or reply_to_comment by describing the trigger-action pattern. An agent can immediately tell this creates an automation rule, not a one-off message.

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

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

Provides clear context for when to use this tool: setting up an automation on an Instagram account or Facebook Page. It mentions targeting behavior but does not contrast with create_dm_automation or list_comment_dm_rules explicitly. The usage scenario is implied rather than stated as 'use this instead of X'.

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

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

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-destructive write that doesn't interact with external systems. The description adds critical behavioral context: the link's 24-hour default lifetime and the platform constraint. However, it doesn't detail rate limits, permission requirements, or what happens if a link is created and never used.

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, then the platform list, then usage instructions. The long platform enumeration is necessary for clarity, though it slightly bloats the text. Every sentence serves a purpose, but the platform list could arguably be moved to the schema.

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

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

Given no output schema, the description properly explains the return value (a URL) and instructs the user to share it. It also includes the link's expiration behavior and the follow-up call, covering all needed context for correct invocation and post-invocation 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 coverage is 100%, so the schema already documents all three parameters with defaults and enums. The description repeats the platform list and the expiresInHours override, adding no new syntactic or semantic detail beyond what the schema provides. 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?

States a specific verb ('Create a link') and resource (account-connection link), and uniquely distinguishes itself from siblings like list_accounts or create_workspace. The enumeration of supported platforms clarifies the scope without ambiguity.

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

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

Explicitly states the condition ('without a Breakreach login'), the action ('Give the URL to the person to open in a browser'), and the follow-up step ('Call list_accounts afterwards to get the new account ids'). These are clear when-to-use and next-step instructions that leave no inference required.

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 only say readOnlyHint=false, openWorldHint=true, destructiveHint=false, and the description adds substantial behavioral context beyond that: the 24-hour Meta reply window, one flow per person at a time, manual team replies halting the flow, and messages due after the window silently not sending. It also discloses hard limits (40 steps, 6 branch levels, 23h max wait) and the destructive-ish consequence of pausing with active=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?

Purpose and constraints are front-loaded in the first paragraph, and every prose sentence (24-hour window, one flow per person, handoff stops it) earns its place. The trailing example is a large inline JSON blob with elided `[...]` segments that duplicates much of the steps schema, which is the main drag on size.

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

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

For a complex, nested, write tool with no output schema, the description covers runtime behavior, limits, and trigger semantics well. It does not say what the call returns (e.g. the created automation id) or what permissions the account needs, which is a modest gap given no output schema exists.

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 88% and the nested trigger/steps schemas are exhaustively documented in the schema itself. The long inline JSON example mostly restates the per-step semantics the schema already gives, adding only marginal value in showing how trigger and steps compose. Baseline 3 is appropriate 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 ('Create a DM automation on an Instagram account (or a Facebook Page, Messenger)') and even summarizes the runtime behavior of the artifact it creates. However, it never names or contrasts with the close siblings create_comment_dm_rule and update_dm_automation, so an agent must infer the boundary from the name alone.

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

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

Usage is only implied through the trigger types and the note that it 'only ever replies to something the person did, within Meta's 24-hour window' — useful scoping, but not stated as when-to-use guidance. There is no explicit when-not or 'use X instead' routing against update_dm_automation or create_comment_dm_rule.

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 cover the safety profile (not read-only, not destructive, open-world); the description goes well beyond them, disclosing consequential platform behaviors such as photos being cropped to the first photo's shape in Instagram/LinkedIn carousels, LinkedIn converting photos into a PDF carousel, per-network media-count limits, and timezone interpretation of scheduledAt.

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 opening sentence front-loads purpose and modes effectively, and the dense platform detail is largely justified by 18 parameters and eight nested settings objects. It is delivered as one long undifferentiated paragraph, so scanning is harder than it needs to be and a few clauses restate schema content.

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

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

For a high-complexity, 18-parameter mutation tool the platform semantics are covered thoroughly, including the partial error path for Reddit flair. The remaining gap is that, with no output schema, the description never says what a successful call returns (post id, per-account results), which an agent needs to chain follow-up calls.

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 real conditional meaning the schema does not encode — which networks require media, which settings objects apply to which target, and platform-specific quirks (Tumblr photo caps, Hashnode Pro requirement, Google Business 1,500-character limit).

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

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

States a specific verb and resource ('Create a social media post') and immediately enumerates the three operating modes: schedule, publish immediately, or save as draft. The per-network elaboration makes it unmistakable against siblings like update_post or delete_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?

Gives explicit routing guidance: 'use upload_media first for reliable hosting' and 'use list_pinterest_boards' for the board id, plus the conditional rule that media is REQUIRED for Instagram/TikTok/YouTube/Pinterest except drafts. The mode selection (draft vs publishNow vs scheduledAt/useNextSlot) is spelled out rather than inferred.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine context beyond that: the created workspace is isolated (its own accounts, posts, schedule) and its slug is the handle other tools need. It says nothing about name uniqueness, failure modes, or rate limits, so it stays at a solid-but-not-rich 3.

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 filler, and the core action is front-loaded ahead of the downstream-usage note. Every clause carries information the agent needs.

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

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

With no output schema, the description usefully compensates by implying the slug is the returned handle to reuse elsewhere. It is complete for a simple 2-parameter create, though it omits duplicate-name behavior and does not explicitly state what the call returns.

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 are already documented (including the UTC default), so the baseline is 3. The description earns above baseline by introducing the slug — an identifier not present in the schema — and telling the agent where it is consumed, which clarifies the output contract of the call.

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

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

States a specific verb+resource ('Create a workspace') and scopes it to 'a new brand or client', which immediately distinguishes it from the list/update workspace operations. It also explains what a workspace contains (connected accounts, posts, schedule), so an agent understands the resource it is creating.

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 clear trigger ('for a new brand or client') and a forward-looking rule for downstream use ('pass its slug as workspace to the other tools'), which tells the agent when this tool must be called first. It does not, however, mention the alternative list_workspaces or what to do if a workspace for that brand already exists.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description reinforces the permanence of the operation. It adds value beyond the annotations with platform capability limits (Google does not permit deleting reviews, only the business reply), which is behavioral context the annotations cannot express. It stops short of describing failure modes or confirmation requirements.

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

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

Three tight sentences, front-loaded with the destructive action and followed by the preference rule and platform specifics. No filler or redundant 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, so the description carries the return-value burden, and it does not say what a successful deletion returns. It fully covers platform scope, the hide-vs-delete decision, and ID sourcing, which is most of what an agent needs for a 4-parameter destructive tool.

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

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

Schema coverage is 75%, so a baseline of 3 applies, but the description genuinely adds meaning: it redefines commentId as the review id for Google Business Profile, which the schema's generic 'The comment to delete' does not convey. It also tells the agent where to obtain accountId, platform and commentId, covering the required set.

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 ('Permanently delete a comment') and immediately scopes platform behavior, including the Google-specific nuance that it deletes the business's reply rather than the review. An agent can distinguish this from hide_comment on the permanence axis 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 routes the agent: 'Prefer hide_comment unless the user explicitly asks to delete,' naming both the alternative and the condition that selects it. It also points to list_recent_comments and get_post_comments as the source of the required IDs.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so permanence is partly covered. The description adds genuine value by disclosing that associated stats and activity are destroyed too, which the annotation does not convey. It stops short of stating auth requirements or whether the deletion is recoverable beyond the phrase 'for good'.

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, and the primary destructive action is front-loaded before the safer alternative. 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 destructive delete with no output schema, the description covers permanence, side effects on stats/activity, and the softer alternative. Nothing critical is missing, though it could note whether the ruleId must exist or what happens on a bad 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 schema distinguishes ruleId (from list_comment_dm_rules) and the optional workspace slug. The description adds no parameter-level detail, so this is the baseline 3 for a fully documented 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 ('Delete') and resource ('Comment to DM rule'), and immediately contrasts with its sibling update_comment_dm_rule. An agent can distinguish this from update/delete_dm_automation 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 names the alternative and the condition that selects it: 'To stop it for a while instead, use update_comment_dm_rule with active false.' This is a textbook when-not routing instruction.

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, but the description goes further by disclosing exactly what is destroyed (the automation plus its stats and runs) and the runtime side effect (people currently in the flow stop). 'For good' communicates irreversibility, which the annotations alone do not 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?

A single sentence with the destructive consequence front-loaded and the alternative routed at the end. No filler, and the most decision-relevant information comes first.

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

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

For a two-parameter destructive tool with no output schema, the description covers everything an agent needs: what is removed, what happens to live flows, and the safer alternative. Nothing material is missing.

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

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

Schema description coverage is 100% and the schema already documents both workspace and automationId, including the pointer to list_dm_automations. The description adds no parameter-level syntax or format detail, so the baseline 3 applies.

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

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

The description names a specific verb ('Delete') and resource ('a DM automation') and adds scope ('with its stats and runs'). It distinguishes itself from the update sibling by explicitly contrasting permanent deletion with pausing, so an agent can separate the two 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 an explicit when-not and names the alternative: 'To stop it for a while instead, use update_dm_automation with active false.' The selection condition between the two tools is spelled out rather than 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 declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: scheduled posts are merely unscheduled, and published posts are removed from Breakreach but not from the underlying platforms. It does not state reversibility or permission requirements, 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 core action front-loaded and the nuanced scheduling/publishing behavior immediately after. 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?

There is no output schema, but the tool is a simple two-parameter mutation and the description covers the essential downstream effect an agent needs to know. What remains unstated (return value, reversibility, workspace scoping effect) is minor but not fully covered.

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 both parameters, so the schema already documents 'postId' and the optional 'workspace' slug. The description only restates that deletion is by id and adds no format, constraint, or scope detail for the workspace parameter.

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

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

States a specific verb (Delete) and resource (post), scoped by id, which cleanly separates it from siblings like delete_comment and delete_dm_automation. The second sentence further pins the operational meaning of the action.

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 operation itself, and no sibling alternative for removing a post is named (update_post, list_posts). It does implicitly distinguish the outcome for scheduled vs published posts, which is helpful, but there is no explicit when-to-use or 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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower; the description still adds real behavior beyond them by disclosing the 1-hour cache and the partial metric availability per platform. It does not describe response shape or pagination, which are minor gaps here.

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

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

One front-loaded sentence delivering the purpose, metric list, platform list and cache note with no filler. The long platform enumeration is dense but earns its place by defining coverage boundaries.

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 sensibly enumerates what is returned (followers, 28-day views, reach, engagement, profile views) and notes caching. The only missing element is how the workspace parameter alters scope, which is minor for a near-zero-arg read tool.

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

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

There is a single optional parameter (workspace) whose schema description coverage is 100%, so the schema already carries its meaning; the description never mentions workspace scope at all. With full coverage the baseline of 3 is appropriate, as the description adds nothing parameter-level.

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 account-level stats for every connected account') and enumerates the metrics returned, which implicitly separates it from post-level siblings like get_post_metrics. It does not explicitly name the alternative account-level tools (get_account_trends, get_analytics), so it stops short of full sibling differentiation.

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

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

The scope ('account-level', 'every connected account') implies when to reach for this over per-post tools, but there is no explicit when-to-use/when-not guidance or named alternative. The platform caveat ('where the platform exposes them') is useful context but not 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 establish readOnlyHint, destructiveHint false, and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior beyond that: a 1-hour cache that is bypassed when refresh is true, a 90-day ceiling, and the fact that gap days are still returned. It does not describe volume limits or partial-failure behavior across platforms.

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, front-loaded with the core scope (daily trends, max 90, source platforms) before the secondary caching caveat. Every clause carries information the agent needs; nothing is 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 correctly takes on the return-value burden, naming the per-platform metrics and the per-account summary of totals and follower change. There is no output schema or pagination concern, and no required parameters exist, so the remaining gap is minor: it never says what happens when an account has no insights or how multiple accounts are keyed in the response.

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 days, refresh, accountId, and workspace are all already documented in the schema, including the default of 30 and the 1-to-90 range. The description restates the max 90 and cache/refresh relationship but adds no syntax, format, or edge-case detail beyond what the schema provides, 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 states a specific verb and resource (daily account-level trends) with a clear scope: last N days, max 90, one row per day. It also enumerates the platforms and metrics returned (Facebook views/engagement/followers, Instagram reach, Threads views), which separates it from post-level siblings. It stops short of naming the adjacent tools (get_account_stats, get_analytics), so the trends-vs-stats distinction must 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 context is implied rather than stated: 'works even for days without new posts' and the cache/refresh note hint at when this is preferable to a live call. There is no explicit when-to-use or when-not-to-use guidance, and no routing to get_account_stats or get_analytics for point-in-time or cross-resource analytics.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds scope value ('aggregated', 'published posts only', plus the metric set and top-performing posts), but says nothing about whether results are filtered by time range, how 'top performing' is ranked, or any rate limits.

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

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

A single compact sentence that front-loads the verb and resource and then lists the payload. No wasted words, though it is arguably under-informative rather than optimally sized.

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 useful double duty by naming the returned metrics and flagging top-performing posts. But for a tool embedded in a dense analytics/metrics family with no sibling differentiation and no time-scope caveat, it leaves real gaps for correct invocation.

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

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

There is one optional parameter (workspace) and schema description coverage is 100%, so the schema fully documents it. The description neither mentions the workspace filter nor adds format or scoping detail beyond what the schema already provides, which matches the baseline 3.

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

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

States a specific verb and resource ('Get aggregated analytics for published posts') and enumerates the returned metrics, which is clear. However, it does not distinguish itself from the several analytics/metrics siblings such as get_post_metrics, get_account_stats, and get_content_performance, leaving an agent unsure which one to pick.

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, and no routing to alternative tools despite a crowded analytics family in the sibling list. The agent must infer the use case entirely.

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

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

Annotations already establish read-only, non-destructive, open-world. The description goes beyond them with real operational detail: a max 365-day window, a 1 hour cache with 'refresh is true' to rebuild (noting it is slower), and the explicit data-coverage caveat that non-Breakreach posts are included, which concretizes the openWorldHint. No authentication or rate-limit behavior is mentioned.

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 compact sentences, front-loaded with purpose and scope before the usage tip and the caching caveat. Every sentence carries information, though the metric enumeration and the cache sentence could be tightened slightly.

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 helpfully outlines the return shape (per-post metrics plus totals per platform) and covers the cost/latency tradeoff of refresh, so an agent can call it correctly. Minor gaps remain: no mention of pagination behavior past the limit cap or how results are ordered when sorting by a non-date field.

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 and the schema already documents days (1-365), limit (max 200), sortBy enum, and refresh semantics. The description mostly restates those bounds and adds only the sortBy+limit combination example, which is a marginal gain over what the schema provides.

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

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

States a specific verb+resource (per-post performance metrics) and enumerates the returned measures (views, likes, comments, shares, engagement rate, per-platform totals). The scope sentence 'Covers ALL posts on the connected Instagram, Facebook, Threads, X, YouTube and Bluesky accounts, including posts not made with Breakreach' distinguishes it from single-post siblings like get_post_insights and get_post_metrics without needing to open 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?

Gives actionable usage context, including a concrete pattern: 'Use sortBy + limit for top posts, e.g. sortBy=views, limit=10.' It also frames the refresh flag as the escape hatch from the 1 hour cache. It stops short of naming when NOT to use it or naming sibling alternatives (get_analytics, get_account_trends), 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=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds the useful ordering trait (oldest first) and the platform-conditional participantId requirement, but says nothing about pagination, result limits, or rate constraints.

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 purpose and ordering front-loaded, followed by the prerequisite sourcing information. No filler or redundancy.

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

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

With no output schema and annotations covering the read-only safety profile, the description covers what the tool does and how to obtain inputs. The notable omission is any mention of pagination or result-window behavior for a message list that could be long.

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

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

Schema description coverage is 100%, so all four parameters are documented in the schema itself, including the 'required for X' note on participantId. The description largely restates that sourcing instruction rather than adding syntax, format, or default-value detail, 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 (Read) and resource (messages of one DM conversation) plus the ordering guarantee (oldest first). It is clearly distinguishable from list_conversations, which supplies the identifiers rather than the message bodies.

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 to list_conversations to obtain conversationId, accountId and participantId, and notes the conditional requirement that participantId is required for X. It does not name a competing tool or state when-not to use this one, so it falls short of full alternative coverage.

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 read-only, non-destructive, closed-world call, so the safety profile is covered. The description usefully adds that the result derives from the workspace's *configured* posting schedule, implying a configuration dependency, but it does not say what happens when no schedule is configured or when every slot is taken (null vs. 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?

Two tight sentences: the definition is front-loaded and the usage hint follows. No filler, no restating 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?

There is no output schema, so the description is the only source for what comes back. It states the result is 'a time', but gives no format (ISO timestamp, local vs. UTC, object shape), no pagination or fallback behavior, and no error/no-available-slot semantics. Adequate to select the tool, incomplete for interpreting the result.

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

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

Schema description coverage is 100% for the single optional 'workspace' slug parameter, so the schema already carries the parameter meaning. The description never mentions the parameter or its default resolution behavior, so it adds nothing beyond the schema — the baseline 3 applies.

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

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

The description names a specific verb and resource ('get the next free posting slot') and then defines the concept operationally as 'a time not already taken by a scheduled post', removing any ambiguity about what 'free' means. No sibling tool touches scheduling slots, so the agent can distinguish it immediately.

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 use context via the quoted question 'when should I post next?', which tells the agent what intent this tool serves. It does not name alternatives or state when-not to use it (e.g., how it relates to create_post or list_posts scheduling), so it falls short of explicit 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 already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior beyond the annotations: comments are fetched 'live from the platforms' (no cached/stale copy) and the supported platform set is enumerated, which matters given the open-world hint. It omits rate limits, pagination, and ordering.

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: the first gives the action and scope, the second gives platform coverage. Front-loaded with the verb and resource and free of 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 two-parameter read tool with full schema coverage and no output schema, the description covers what is read, where the data comes from, and which platforms are supported. It leaves minor gaps an agent might want, such as pagination/limits and result ordering, but nothing blocking correct invocation.

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

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

Schema description coverage is 100% and both parameters are documented in-schema, including the useful cross-reference that postId comes from list_posts. The description adds no additional parameter meaning (e.g. whether workspace changes which accounts are queried), 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 (Read) and resource (comments/replies on a post published with Breakreach), so an agent knows exactly what it returns. It stops short of explicitly distinguishing itself from the closest sibling, list_recent_comments, which reads comments across posts rather than for one 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?

Usage is implied by the scope phrase 'on a post published with Breakreach' plus the required postId, which signals per-post retrieval. However, it names no alternative (e.g. list_recent_comments, get_conversation_messages) and gives no when-not or prerequisite guidance such as needing a connected account.

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, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds real context beyond that: it covers posts not created through Breakreach, enumerates the metric families the platform exposes, and discloses that a benchmark comparison against the account average is included. No pagination, rate-limit, or error behavior is mentioned.

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 payload summary in the first clause, followed by the required-parameter sourcing note. The parenthetical metric enumeration is long but earns its place given there is no output schema to describe return values. Slightly list-heavy but no filler sentences.

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 takes on the return-value burden by enumerating metrics, comments, and the average comparison. It also names the id source, so an agent can chain the call. Minor gap: nothing about behavior for invalid postIds or what a missing-benchmark case returns.

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 three parameters, including that postId is 'the platform post id' and accountId comes from list_accounts/get_content_performance. The description restates the same sourcing guidance without adding format, validation, or edge-case detail. Baseline 3 applies when the schema carries the weight.

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

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

States a specific verb and resource ('everything about one post on a connected account') and enumerates the scope: caption, media, lifetime metrics, comments, and an average-post comparison. This distinguishes it from the overlapping siblings get_post_metrics and get_post_comments by framing itself as the comprehensive superset, and it notes the unusual inclusion of posts not published with Breakreach.

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 does give the prerequisite for the ids ('Take accountId and postId ... from get_content_performance'), which is useful routing. However it never states when to prefer this tool over the directly overlapping get_post_metrics or get_post_comments, nor any exclusion. Usage is implied by 'everything about' rather than declared.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: it discloses the returned payload (metrics plus platform post ids) and that refresh triggers a slower external fetch from the platforms. No auth or rate-limit notes, but it exceeds the annotation bar.

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, purpose front-loaded, parameter guidance second. Every clause carries 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?

Complete on the essentials: read-only safety comes from annotations, returned values are enumerated since there is no output schema, and refresh behavior is explained. The one meaningful omission is sibling differentiation in a crowded analytics namespace.

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 three parameters are documented, and the description's refresh note largely restates what the schema already says ('Fetch fresh metrics... slower'). Baseline 3 is appropriate since the description adds little beyond the structured fields.

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

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

States a specific verb and resource ('Get views, likes, comments and shares for one post') and scopes it to a single Breakreach post, plus notes it returns platform post ids. However, it gives no differentiation from closely related siblings like get_post_insights or get_content_performance, leaving the agent to guess which one to pick.

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

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

The only guidance is a parameter hint ('Set refresh to pull fresh numbers from the platforms first'), which tells how to use refresh but not when to use this tool versus get_post_insights, get_content_performance, or get_analytics. Given the dense cluster of similarly named analytics siblings, the absence of any when/when-not routing is a real gap.

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

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

Annotations declare the safety profile (not read-only, non-destructive, open-world), and the description adds genuinely new behavior: the hide is reversible and the comment is not deleted. It also scopes supported platforms (Instagram, Facebook, Threads), which the annotations do not cover.

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, no filler, with the primary action and its reversibility guarantee front-loaded before the platform list and ID sourcing.

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 non-destructive mutation with no output schema, the description covers effect, reversibility, platform support, and parameter sourcing. It doesn't mention required permissions or what the call returns, which would round it out.

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 80% (hide flag, accountId, commentId documented in-schema), so the baseline is low-3, but the description adds real provenance value by naming the two sibling tools that supply commentId/accountId/platform.

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 (hide/unhide) on a specific resource (comment), gives the motivation (spam, trolls, off-topic), and implicitly distinguishes itself from the destructive sibling delete_comment by noting the comment 'isn't deleted'.

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?

Names the triggering scenarios (spam, trolls, off-topic) and tells the agent where the required identifiers come from (list_recent_comments or get_post_comments). It stops short of an explicit 'use delete_comment instead when...' exclusion, so it is clear context rather than 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the return shape (id, platform, display name) in the absence of an output schema, and by indicating the ids are reusable identifiers. It does not mention pagination or workspace scoping.

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

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

Two short sentences, front-loaded with the identity of the tool and the return fields, followed by the actionable usage hint. No filler or 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 zero-required-parameter read-only list tool with no output schema, the description covers what it returns and how to consume the ids, which is enough to call it correctly. Minor gaps remain around workspace scoping and whether results are paginated.

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 optional 'workspace' parameter whose schema description is present (100% coverage), so the schema carries the parameter documentation. The prose adds nothing about the workspace slug's format or what happens when it is omitted. 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?

States a specific verb and resource ('List connected social media accounts') and even enumerates the returned fields (id, platform, display name). An agent can distinguish it at a glance from siblings like get_account_stats or get_account_trends, which report metrics rather than enumerate accounts.

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 returned ids as accountIds when creating posts' gives concrete downstream context, effectively naming create_post as the consumer of this output. However, it offers no exclusions or alternatives (e.g., what to use if you need stats instead), so it stops short of a full when/when-not statement.

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

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

Annotations already declare readOnlyHint and destructiveHint=false, so safety is covered. The description goes further and, with no output schema, enumerates the returned fields (account, post or every post, keywords, DM text, public replies, on/off, stats) and what ruleId adds (commenter identity and sent/failed/skipped with failure reason).

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 front-loaded sentences with no filler; the concept definition comes first and the ruleId behavior second. It is dense but every clause carries information an agent needs.

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

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

For a read-only list tool with no output schema, the description adequately covers the return shape and the optional drill-down. Minor gap: no mention of pagination or result limits when listing many rules.

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 clarifies the effect of ruleId (adds latest activity) but adds no syntax or format detail for accountId or workspace beyond what the schema already 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?

States a specific verb (List) and resource (Comment to DM automations), then defines the concept precisely: a keyword comment on an Instagram or Facebook Page post triggers an automatic DM. This clearly separates it from siblings like list_dm_automations and the create/update/delete_comment_dm_rule family.

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

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

It explains the conditional drill-down (pass ruleId to also get latest activity), which is useful usage guidance. However, it never states when to prefer this over list_dm_automations or when not to use it, so routing between the two listing tools 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 (readOnly, non-destructive, openWorld), and the description adds real value beyond them: newest-first ordering, the per-conversation fields returned, and the partial-failure behavior where unloadable accounts surface in an errors array with reasons such as missing message access.

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, with the resource and ordering front-loaded and the return/error behavior second. 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?

With no output schema, the description usefully enumerates the returned fields (id, accountId, participantId, last message) and the errors array. It is close to complete for a read-only list tool, though it omits pagination/limit behavior.

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 platform, accountId and workspace; the baseline is 3. The description only reinforces the platform values by naming the three supported networks, adding little for accountId or workspace.

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 ("List direct message conversations") plus ordering and the exact platform scope (Facebook Pages/Messenger, Instagram, X), which cleanly separates it from the sibling get_conversation_messages that fetches messages inside a conversation.

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 can infer this is the entry point before get_conversation_messages, but the description never states when to prefer it over alternatives or any prerequisite (e.g., needing a connected account). No exclusions or routing guidance are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds substantial behavior beyond that: the exact stat set returned (started, completed, handed off, link clicks, failed) and the run-level outcomes including the 24-hour window closing and human handoff. It does not mention pagination or result limits.

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

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

Two sentences, front-loaded with the core listing behavior before the automationId extension. The parenthetical enumerations are dense but each carries real information about trigger types and run outcomes 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?

With no output schema, the description carries the return-value burden and does so well, covering both the automation summary fields and the detailed run fields. Minor gaps remain: no pagination/limit behavior and no statement about what happens for an unknown automationId.

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 nonetheless adds meaning by explaining that automationId is not a filter but a mode switch that also returns the latest runs, and by spelling out what those runs contain (who triggered, steps sent, choices tapped, clicks, how it ended).

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) plus a precise resource (DM automations) and immediately defines what an automation is: flows of messages, waits, conditions and handoffs run in Instagram DMs and Messenger. It is clearly distinguishable from the create_/update_/delete_dm_automation siblings and from list_comment_dm_rules.

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 context in which these objects exist (keyword DMs, story mentions, story replies, ref links) and explicitly tells the agent that passing automationId switches the call into a run-listing mode. It does not name any alternative tool or state when-not to use this one, 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=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context beyond them: the listing is scoped to a single connected Pinterest account per workspace and is a prerequisite step in the Pinterest posting flow. It still omits pagination/result-count 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?

Two short sentences, both earning their place: the first defines the resource and scope, the second front-loads the actionable prerequisite. 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 carries the burden of explaining what comes back, and it does not — an agent cannot tell whether board identifiers (needed for create_post) are returned. The workflow context is adequate but the return-shape gap leaves it only minimally complete.

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

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

The single 'workspace' parameter has 100% schema description coverage, so the baseline is 3. The phrase 'of the workspace's connected Pinterest account' implies the workspace scoping, but the description does not clarify the optional/default-workspace semantics that the schema already gestures at, so it adds little.

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 the Pinterest boards') and narrows scope to the workspace's connected Pinterest account, which distinguishes it from generic siblings like list_accounts or list_workspaces. It stops short of explicitly naming a sibling it differs from, which is what a 5 would require.

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?

'Required before creating a post targeting Pinterest' gives a clear workflow precondition tied to a real sibling action (create_post). It states when to use the tool but offers no exclusions or alternates (e.g. what to do if no Pinterest account is connected), 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 readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing behavioral beyond that — no pagination or ordering semantics despite a limit parameter, and no note on how unpublished vs published posts differ — so it is minimum-viable rather than additive.

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

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

A single front-loaded sentence with no filler; scope and returned fields come first. It is efficient, though so terse that it omits useful qualifiers rather than being padded.

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, and the description partially compensates by naming the returned data (status, schedule time, metrics for published posts), which is genuinely useful for a read tool. Gaps remain around result ordering and pagination, but nothing needed to issue the 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 100%: limit (default 25, max 100), status enum with default, and workspace slug are all documented in the schema. The description only gestures at 'status' and adds no syntax or defaulting detail beyond what the schema already carries, 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?

Specific verb+resource ('List posts') with a stated scope ('in the workspace') and the fields surfaced. It does not name or contrast any sibling such as get_post_metrics or get_post_insights, so the agent must infer the boundary itself.

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

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

No when-to-use guidance and no exclusions. With 30+ siblings including list_accounts, list_workspaces, get_post_metrics and get_analytics, the description never states that this is the bulk-listing entry point rather than a per-post or analytics tool.

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

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

Annotations cover the read-only/non-destructive safety profile, so the bar is lower, yet the description adds substantial beyond-annotation behavior: the newest-first ordering, the 10-post and 50-review window limits, the nesting of replies, and the Google moderation status semantics. It omits whether results are paginated or how many comments are 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?

It is front-loaded with the main scope statement, which is good. However, the middle is a densely stacked single sentence that packs platform lists, a parenthetical, and a mapping rule, making it hard to parse; it earns its place informationally but structure suffers.

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

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

For a read-only list tool with no output schema, it conveys the important return-shape facts an agent needs (comment id/accountId/platform for follow-up tools, nested replies, Google rating and status semantics). The absence of pagination/volume details and explicit sibling routing are the remaining gaps.

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

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

Schema coverage is 100% and each parameter is documented in the schema (including the enum and the list_accounts reference), so the description doesn't need to carry that load. It adds the googlebusiness = Google reviews clarification and the review-as-comment model, but no syntax beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('List recent comments') and precisely delineates scope across five platforms, including the unusual Google Business review mapping (each review is a comment). It clearly distinguishes itself from the sibling get_post_comments by covering an account-wide recent feed rather than a single 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?

Clear context is given: it's the recent-comments feed, newest first, with the 10-post/50-review window cap. However, it never explicitly names get_post_comments as the per-post alternative or states when NOT to use this tool, leaving the routing to inference from the sibling name.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the returned fields and the fallback behavior that the first workspace is used when a slug is omitted, which affects how downstream calls behave. Pagination and scoping to the current user are not addressed.

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

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

Two tight sentences; the resource description and return fields come first, followed by the cross-tool convention. No filler or repetition.

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

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

With no output schema and no parameters, the description carries the burden of explaining what comes back, and it does so by naming the three returned fields. Combined with the workspace-slug fallback note, an agent has everything needed to call this tool correctly and use its result.

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

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

The tool takes zero parameters, so the baseline is 4. The description's mention of an optional workspace slug applies to sibling tools rather than this one, so it adds context but no parameter detail here.

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 Breakreach workspaces) and names the returned fields (slug, name, timezone). This distinguishes it clearly from the many other list_* siblings such as list_accounts and list_posts, which return 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?

Adds real routing guidance by explaining the workspace-slug convention: most tools take an optional workspace slug and default to the first workspace when omitted, which implicitly tells the agent why and when to call this tool first. It stops short of explicitly naming alternatives or stating when NOT to use it, so it isn't a full 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 flag destructiveHint=true and openWorldHint=true, and the description explains the behavior behind that destructiveness: on Google Business Profile a review has only one business reply, so replying again replaces it. It also adds real constraints the annotations cannot express (YouTube replies attach to the top-level comment, 4,096-byte limit, verified locations only, Google moderation leaves status pending). It is dense with behavioral context, though it does not say what a successful call returns.

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 purpose, then platform-specific caveats in compact parentheticals; almost every clause carries a constraint an agent needs. The Google Business Profile parenthesis is long and stacks several rules, which mildly taxes readability, but 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?

Covers platform quirks, ID sourcing, size limits, moderation, and the replacement behavior for a mutation tool with no output schema and adequate annotations, so an agent can call it correctly. The only gap is that it never indicates what the call returns (e.g., the new reply id or the pending status value), which would help confirm success.

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

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

Schema description coverage is 80%, so the baseline is 3, and the description clears that bar by adding semantics the schema lacks: commentId doubles as the review id on googlebusiness, and the message is capped at 4,096 bytes on that platform. The platform enum is also spelled out. Only the optional workspace parameter is untouched, which is acceptable.

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 (reply to a comment) plus its extension (answer a Google review), and enumerates the exact platforms supported. An agent can distinguish it from hide_comment, delete_comment, and send_message without consulting either schema.

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

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

Explicitly tells the agent where to obtain commentId, accountId and platform ('from list_recent_comments or get_post_comments'), which removes the main routing ambiguity. It does not, however, state when to prefer this over send_message for a reply-like DM, so there is no explicit exclusion.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuine behavioral context beyond them: the 24-hour reply restriction on Instagram and Messenger and the platform scope. It omits rate limits or failure behavior, but the 24h constraint is a valuable disclosure.

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

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

Three tight sentences, front-loaded with the action and platforms, then the constraint, then the ID sourcing. Every sentence carries distinct information with no filler.

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

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

No output schema exists, and the description doesn't describe the return value, but annotations cover safety and the schema fully documents all five parameters. For a send tool the remaining gap (response shape, attachments) is minor, leaving it nearly 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 adds relational meaning beyond the schema by specifying that conversationId and/or participantId come from list_conversations and that at least one is needed, clarifying how the ID parameters combine.

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 ('Send a direct message reply') and enumerates the target platforms (Messenger, Instagram, X). This implicitly separates it from siblings like reply_to_comment and create_post, though it never names an alternative explicitly.

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

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

Gives clear entry context: use accountId plus conversationId and/or participantId from list_conversations, and notes the platform-specific 24-hour reply window. It lacks explicit when-not-to-use guidance (e.g., outside the 24h window or for comments vs DMs), so it stops 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=true, and openWorldHint=true. The description adds useful context beyond them: partial-update semantics ('Only the fields given change') and pause/resume via active. It does not detail destructive side effects, but the partial-update note meaningfully refines mutation 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?

Two dense sentences front-load the field list and partial-update rule, with the id-source instruction at the end. Every sentence earns its place and 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?

For an 8-param mutation tool with full schema coverage and no output schema, the description supplies essential context: mutable fields, partial-update behavior, and id sourcing. Slightly more could be said about error conditions or workspace placement, 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 description coverage is 100%, so every parameter is already fully documented with enums, null semantics, and limits. The description largely restates the same fields without adding new 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?

States a specific verb ('Change') and resource ('Comment to DM rule'), enumerates the mutable fields, and clarifies partial-update behavior. It routes the agent to list_comment_dm_rules for the id, distinguishing it from create/delete siblings.

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

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

Gives a clear prerequisite (get the rule id from list_comment_dm_rules) and states that only supplied fields change. It does not explicitly name when not to use this tool or compare with update_dm_automation, 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?

With annotations already declaring destructiveHint=true, the description explains what actually gets destroyed: steps is a full replacement of the whole list, and dropping step ids of unchanged steps breaks people currently in the flow. That in-flight-run consequence is exactly the kind of context the annotation hints 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 compact sentences, front-loaded with purpose and mutation semantics, then the id-source and the step-id caveat. Nothing is filler given the 8-parameter nested schema this sits above.

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

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

For an 8-parameter, nested-object mutation with no output schema, the description covers prerequisites, partial-update behavior, and the riskiest nested field. It is only slightly short in not hinting at what the call returns or any permission constraints.

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 3 baseline applies, but the description still adds operational meaning beyond the schema: automationId is sourced from list_dm_automations, steps must reuse existing ids, and unspecified fields are left untouched. It does not add syntax detail for active/reentry beyond the schema, hence 4.

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 (Change) and resource (DM automation) and enumerates the mutable fields (name, trigger, steps, reentry, active), which makes it clearly distinct from create_dm_automation and delete_dm_automation. It only references list_dm_automations as an id source rather than explicitly contrasting the siblings, so a 4 rather than 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?

"Get the id from list_dm_automations" and "the whole list, as returned by list_dm_automations" give a concrete prerequisite workflow that presupposes a prior list call, and "Only the fields given change" frames this as a partial update. There is no explicit when-not-to-use guidance or exclusion vs create_dm_automation, so it stops short of 5.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-annotated behavior: partial-update semantics ('Only the fields you pass change'), the state machine linking scheduledAt/useNextSlot/publishNow to scheduling and retrying a failed post, and the immutability of published posts.

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 short sentences, front-loaded with applicability ('Edit a draft, scheduled or failed post') before the parameter behavior. No filler, no restatement of the title, and each sentence carries a distinct 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 an 18-parameter tool with nested per-platform objects and no output schema, the description covers the update model, the scheduling side effects and the one hard restriction, which is the right level of detail. Return values need not be explained; the only omission is that it doesn't warn that accountIds overwrites existing 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 coverage is 100%, so the baseline is 3, but the description adds interaction semantics the schema cannot express — that scheduledAt, useNextSlot and publishNow all schedule (and retry a failed post) and that draft:true reverts a post to drafts. It still doesn't flag that accountIds replaces existing targets, which is the riskiest param behavior.

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

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

Opens with a specific verb+resource and immediately scopes it: 'Edit a draft, scheduled or failed post' followed by the editable facets (text, media, target accounts, time, platform options). An agent can distinguish it from create_post, delete_post and list_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?

Gives a clear when (draft/scheduled/failed posts) and an explicit when-not ('Published posts can't be edited'), plus the trigger conditions that reschedule or retry a post. It does not name an alternative tool (e.g. create_post) for the published-post case, so it falls just short of a full routing statement.

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 write (readOnlyHint=false), open-world (openWorldHint=true) and non-destructive. The description adds genuinely new context: the source is an external public URL, the file is copied into Breakreach storage, and a permanent URL is returned. It omits failure modes, size/format limits and auth requirements, which keeps it below 5.

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

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

Three short sentences, front-loaded with the core action and destination storage. The final two sentences about create_post and scheduled posts partially overlap, so there is a small amount of redundancy rather than zero waste.

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

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

With no output schema, the description correctly fills the gap by stating the return value (a permanent URL for create_post), and a single required parameter keeps the surface simple. Missing limits/auth detail keeps it from being fully 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?

Only one parameter and schema coverage is 100%, so the schema already documents the URL field. The description reinforces that it must be a public URL but adds no syntax, size, or format guidance beyond that, so the baseline of 3 applies.

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

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

Specific verb chain (download from a public URL, host it on Breakreach storage) applied to a concrete resource (image or video). It also names the downstream consumer, create_post, so an agent can distinguish this from unrelated siblings like list_pinterest_boards or get_content_performance.

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?

States the situation that selects this tool: media must remain reachable for scheduled posts, and points to create_post as the follow-up. It stops short of explicit exclusions (e.g. already-hosted assets) but the context is clear and actionable.

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