dopost

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

Adds real behavior beyond the annotations: dedupe on repeat calls, refresh of last-used metadata for existing entries, and a returned display name. These are consistent with idempotentHint=false (repeat calls mutate the timestamp) and destructiveHint=false (no duplicates created), so nothing is contradicted. It does not state auth requirements or error behavior for an invalid ID/URL.

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, followed by accepted inputs and downstream usage. Every clause carries information; no filler or restatement of the title.

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

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

An output schema exists, so return details need not be explained, and annotations already carry the safety profile. The description fills the remaining gaps (dedupe, refresh-on-repeat, account scoping, downstream consumer) for a two-parameter upsert tool.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the 'URL or numeric ID' format. The description only restates that format and implies the account linkage; it adds no new syntax or constraint beyond the schema, so the baseline 3 applies.

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

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

Starts with a specific compound verb ('Validate and save') and a precise resource ('an X Community') scoped to 'one connected X account'. It is trivially distinguishable from list_x_communities and remove_x_community without opening any schema.

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

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

Provides clear workflow context: the saved community is consumed later via publish_post platformOptions.communityName, so the agent knows why and when to call it. It stops short of explicitly naming alternatives (e.g. list_x_communities to discover IDs, remove_x_community to undo), so no exclusions are offered.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavioral context: the two-minute lead-time requirement, the auto-publishing consequence of every occurrence, and the caution to verify content/schedule before calling. It does not cover auth requirements, rate limits, or failure behavior, but it goes meaningfully beyond the annotations.

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

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

Three sentences, no filler, and the most consequential constraints (timing rule, weekday encoding, irreversible auto-publish) are front-loaded. Each sentence adds a distinct fact an agent needs before calling.

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

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

For a 12-parameter tool with a deeply nested platformOptions object, 50% schema coverage, and no output schema, the description covers the scheduling essentials but omits how the three end-condition parameters relate and what platformOptions actually gates per network. Adequate but with clear gaps given the tool's complexity.

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 50%, so the description has to compensate but only partially does. It usefully pins down two undocumented semantics: weekdays run 0 (Sunday) to 6 (Saturday) and startsAt must be at least two minutes out. It leaves interval, timezone behavior, media, and the endType/endDate/occurrenceCount relationship unexplained, despite mentioning the 'end condition' as a thing to confirm.

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 ('Create a recurring social media post'), and 'recurring' distinguishes it from the one-time publish_post sibling. However, it never explicitly contrasts itself with update_recurring_post or publish_post, so the 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?

It gives a precondition ('first occurrence must be at least two minutes in the future') and a pre-call checklist ('confirm the content, account, schedule, and end condition'), which is useful. But it never says when to choose this over publish_post (one-time) or update_recurring_post (edits to an existing schedule), so usage is only implied.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is fully covered by structured data. The description adds only "from storage," which is already implied by the annotations; it says nothing about irreversibility, confirmation, or side effects on referencing content.

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

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

One short sentence with the action and key both front-loaded and zero redundant text. Nothing to trim and nothing buried.

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

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

For a single-parameter mutation with no output schema, the description plus annotations cover the essential contract, and annotations carry the destructive/idempotent semantics. However, a destructive tool this terse leaves open whether deletion is permanent and what happens to existing posts or analytics referencing the media.

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 mediaId parameter ("The media ID to delete"), so the schema already carries the parameter meaning. Baseline 3 applies since the description adds no format, source, or lookup guidance beyond the schema.

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

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

States a specific verb ("Delete") and resource ("a media file from storage") with the lookup key ("by its ID"), so an agent knows exactly what the tool does. It is implicitly distinguishable from delete_post by the resource noun, but never names or contrasts against the sibling despite a large sibling set that includes delete_post and list_media.

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

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

There is no guidance on when to prefer this tool, no prerequisites, and no mention of what happens to posts that reference the deleted media. The agent gets no signal about when deletion is appropriate versus using list_media or another maintenance tool.

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

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

Annotations already flag destructive=true and idempotent=true, so the description's job is to say what actually gets destroyed, and it does: drafts/pending posts, an entire group when the post belongs to one, plus automatic cancellation of pending delivery. It also discloses the blocking precondition (a published or processing member) and an explicit non-effect (published network content survives), which is precisely the context annotations cannot carry.

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 the core action and then the cascade, the blocking condition, and the exclusion. No sentence is redundant, and each one carries a distinct behavioral fact.

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

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

For a one-parameter destructive tool with full annotation coverage and no output schema, this covers the essentials: what qualifies for deletion, what cascades, what blocks it, and what is preserved. Nothing an agent needs in order to decide to call it is missing.

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

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

There is a single parameter, postId, and schema description coverage is 100%, so the schema already documents it fully. The description adds no extra meaning about accepted ID formats or whether group member IDs are valid inputs; baseline 3 applies 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 (delete a draft or pending post) and narrows the scope twice: it explains that pending deliveries are cancelled and that already-published content is not touched. That scoping lets an agent distinguish it from publish_post, update_recurring_post, or delete_media without opening any schema.

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

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

Gives clear applicability conditions: only unpublished drafts or pending posts, group posts cascade, and published/processing group members block the call. It stops short of naming a sibling to use instead when the target is already published, so the when-not path is stated but the alternative route is left implicit.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds entitlement context the annotations do not: the analytics:read scope and an active paid-plan requirement, which an agent must know before attempting the call. It stops short of mentioning rate limits or the 90-day cap on includeSeries (though the schema carries that).

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 data the tool returns and then the access prerequisite. Every clause earns its place and there is no filler. It is arguably too lean given the tool's complexity, but as a structure/concision judgment it is clean.

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

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

The description covers purpose and access requirements, and the existing output schema relieves it of explaining return values. However, for an 11-parameter, zero-required-parameter analytics tool with only 55% parameter coverage, the absence of any guidance on range selection, metric choice, or sibling routing leaves clear 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?

With 11 parameters and only 55% schema description coverage, the description needs to compensate and does not. Beyond the word 'comparisons' loosely nodding at the comparison parameter, none of days, metrics, platform, accountIds, includeSeries, or the startDate/endDate pairing is clarified. The agent gets almost nothing here that the schema does not already supply.

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 enumerates the resource: canonical account KPIs, account and platform rankings, coverage, comparisons, and freshness. An agent can tell this is an account-level analytics rollup rather than a per-post tool. It does not, however, name any sibling (e.g., get_audience_analytics, get_content_insights, get_post_performance) to draw the boundary explicitly.

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

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

The description gives a hard gating condition (requires analytics:read and an active paid plan), which is genuinely useful for deciding whether the call is even feasible. It does not say when to prefer this tool over the other analytics siblings (audience, content insights, post performance), so selection guidance remains implicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds the required auth scope (analytics:read), which is genuine value beyond the annotations, but says nothing about pagination, date-range behavior, or result characteristics.

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, front-loaded sentences with no filler, and the permission constraint is placed after the scope statement. It is efficient, though the brevity reflects under-specification rather than tightness.

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 tool with 7 undocumented parameters, three enum-controlled, and no explanation of how the metric/dimension/timeframe options interact, the description is too thin. An output schema exists so return values need not be described, but parameter behavior and sibling routing are missing.

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

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

Schema description coverage is 0% across 7 parameters, three of which are enums (metric, dimension, timeframe), so the description carries the full burden and largely fails it. The single word 'breakdowns' loosely hints at the dimension parameter but gives no syntax, defaults, or meaning for days/startDate/endDate.

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 (audience breakdowns) scoped to one account, which is clear enough to distinguish it from most siblings. However, it does not name or contrast with the closest alternatives like get_analytics_overview or get_content_insights, so the differentiation is left to inference.

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

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

The description offers no when-to-use guidance and no routing among the many analytics/content siblings. The only actionable context is the 'Requires analytics:read' prerequisite, which is useful but is a permission note rather than usage guidance.

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

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

Annotations already establish the safe read-only, idempotent profile, so the bar is lower. The description adds genuinely useful context beyond them: the auth scope required and, importantly, that insufficient samples return a readiness state instead of an error, which prevents an agent from misinterpreting a sparse result as a failure.

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 with the payload description front-loaded, followed by the edge-case behavior and the auth requirement. No filler, though the insight names could be more self-explanatory for an unfamiliar agent.

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?

An output schema exists, so return values need not be spelled out, and the readiness-state note covers the main failure mode. However, for an 11-parameter analytics tool with only 55% schema coverage and no sibling routing, the description leaves real gaps an agent must guess at.

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 55% across 11 parameters, and the description explains none of them. Several params (metrics, platform, accountId, accountIds, groupId) lack schema descriptions, and the description does nothing to compensate for those gaps or clarify the days vs startDate/endDate vs includeSeries interaction.

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 enumerates the concrete artifacts returned (Best Time, Best Day, Format Opportunity, Platform Pulse), which separates it from get_analytics_overview and get_audience_analytics. The named insights are somewhat product-jargon, so the boundaries with siblings are implied rather than stated explicitly.

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

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

The only guidance is a precondition ('Requires analytics:read') and a note that insufficient samples surface as readiness state. There is no indication of when to choose this over get_analytics_overview, get_audience_analytics, or get_post_performance, so the agent gets no routing help.

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 read-only, idempotent, closed-world behavior, yet the description adds real value: full-month inclusion for any touched month, privacy-threshold suppression, and an auth/plan requirement. It stops short of disclosing pagination or result-size behavior for a 9-parameter listing tool.

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

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

Four short sentences, front-loaded with what the tool returns, then scope, caveat, and prerequisites. No filler; 'Preserve privacy thresholds' is slightly telegraphic but still 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?

An output schema exists, so return values need not be explained, and auth plus aggregation caveats are covered. However, for a 9-param tool with 44% schema coverage, missing guidance on cursor/limit pagination and on choosing accountId vs accountIds vs workspaceId leaves real 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 only 44% across 9 parameters. The range statement ('Months touched by the range are included in full') usefully explains the days/startDate/endDate interaction, but limit, cursor, groupId, accountId, accountIds and workspaceId get no meaning from the description, and pagination semantics are entirely absent.

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 ('Read stored monthly search keywords for Google Business locations') and clarifies the data is location discovery rather than per-post metrics, which separates it from get_post_performance-style siblings. It does not name the alternative tool directly, so it falls short of a 5.

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

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

Gives prerequisite context (requires analytics:read and an active paid plan) and implies the domain of use, but never states when to pick this over get_analytics_overview or get_content_insights, nor any when-not condition. Usage is inferable from the purpose line rather than spelled out.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the description correctly spends its space elsewhere: it discloses that limits do not inspect a file, do not guarantee publishing eligibility, that the server re-validates files and destination requirements, and that drafts may hold incomplete platform content. These are real behavioral bounds beyond the structured fields, though the closing note about drafts is only loosely tied to this tool's contract.

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 most important information — what it returns and that it must precede publish_post — is front-loaded in the first two sentences. It runs slightly long, and the trailing draft-incompleteness remark is the weakest sentence, but nothing is redundant with the schema or annotations.

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

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

There is no output schema, and the description compensates by enumerating the limit categories returned. Combined with the ordering constraint, the per-platform cadence, and the validation caveat, an agent has everything needed to call this correctly and interpret the result before publishing.

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

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

Schema coverage is 100% and the single platform parameter already lists all valid slugs, so the schema carries the naming burden. The description still adds meaning by framing the call as per-destination-platform and by tying the returned limits to the post type being composed, which goes slightly beyond the schema baseline.

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

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

States a specific verb and resource ("Get content limits for a platform") and immediately enumerates what those limits cover: max text length, media count, supported formats, file sizes, media specifications. This is clearly distinct from siblings like publish_post or list_media, so an agent can route without opening the schema.

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

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

Gives explicit when-to-use guidance ("Call this before publish_post when publishing or scheduling"), the correct cadence ("once for each distinct destination platform"), and how to apply results against the selected post type (feed, story, reel, carousel). An alternative is named and the ordering constraint relative to publishing is unambiguous.

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

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

Annotations already declare this as a safe, idempotent read, so the bar is lower. The description still adds non-obvious behavioral context the annotations cannot convey: the error.message/error.code/error.retryable fields exposed on FAILED, and the important caveat that a successful status query does not mean the post was published.

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 what is returned, then the failure-mode caveat. Every clause earns its place and there is no redundant restatement of the title.

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

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

With no output schema, the description correctly enumerates the payload facets and the error shape, which is what an agent needs to interpret results. Missing only explicit routing against sibling read tools, which is a minor gap for a simple single-parameter getter.

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

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

There is a single parameter, postId, with 100% schema description coverage, so the schema already carries the semantics. The description adds nothing about ID format or source, which is acceptable at this coverage level and lands on the baseline.

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

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

The description uses a specific verb (get) and resource (a specific post) and enumerates the returned facets: content, status, schedule, and social account info. It implicitly separates itself from list_posts by scoping to one post, though it never names that sibling explicitly.

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

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

Usage is implied by 'a specific post' and the FAILED-status troubleshooting note, which tells the agent what to do after the call. However, there is no explicit guidance on when to prefer this over list_posts, get_post_performance, or get_content_insights, and no stated prerequisites.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value beyond that by enumerating the four distinct data categories returned and stating the required permission scope (analytics:read), which the annotations do not convey. No mention of rate limits, caching, or freshness semantics for 'current' metrics.

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

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

Two tightly written sentences with zero filler: the data scope comes first, the permission requirement second. Every clause carries information an agent can act on.

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

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

With an output schema present, the description need not explain return values, and it correctly focuses on scope and authorization. An agent has enough to invoke the tool correctly, though it lacks any routing hint toward the list-level sibling when the target post is unknown.

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 there is only one parameter, postId, which the schema documents as 'dopost post ID'. The description adds no additional meaning about the identifier's format or where to obtain it, so the baseline 3 for high-coverage schemas 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 ('current metrics, cumulative snapshots, collection progress, and external-link availability for one dopost post'), which is far more informative than the title alone. The singular 'one dopost post' implicitly contrasts with the sibling list_post_performance, but no sibling is named explicitly, so the differentiation is inferred rather than stated.

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

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

'Requires analytics:read' gives a concrete prerequisite for calling the tool, which is genuinely useful. However, there is no guidance on when to choose this over list_post_performance or get_analytics_overview, and no statement of when it would not apply, leaving the usage context implied.

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

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

Annotations already establish this as a safe, read-only, idempotent call, so the bar is lower; the description still adds real value by disclosing that no API key is needed and that returned download URLs are temporary. The temporary-URL caveat is exactly the kind of behavior an agent cannot infer from the annotations. It does not describe rate limits or how many formats are typically 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?

Four short sentences, with the core purpose front-loaded and the constraints following in descending importance. The closing permission/legal sentence is arguably boilerplate for tool-selection purposes, but nothing is padded or 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?

With an output schema present, the description need not explain return values, and it correctly focuses on scope, auth posture, and URL temporality. The one gap is that it never positions itself relative to 'prepare_social_media_download', which shares the download workflow and would need disambiguation in a 23-tool list.

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 mode enum with its 'both' default is fully documented in the schema, so the description does no parameter work at all. Per the calibration rule, a 100%-covered two-parameter schema establishes a baseline of 3.

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

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

The description uses a specific verb ('Get') and resource ('MP4 and MP3 download options') and narrows scope to public YouTube, Instagram, or TikTok URLs. It is clear on its own, but it never distinguishes itself from the sibling 'prepare_social_media_download', which an agent will likely need to choose between.

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 a usable condition ('public tool does not require a dopost API key') and an implicit constraint (URLs must be public, from one of three platforms), which is helpful. However there is no when-to-use versus when-not-to-use guidance and no routing to the closely related 'prepare_social_media_download' sibling, leaving the selection decision to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the default cross-workspace scoping and the fact that each account carries workspace metadata, but says nothing about pagination, ordering, 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?

Three short sentences, front-loaded with the scope, then the return shape, then the usage tip. Minimal waste, though 'Each account includes structured workspace metadata' is somewhat abstract and close to filler.

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

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

For a read-only, three-optional-parameter list tool with full annotation coverage and no output schema, the description covers scope, partial return shape, and how to use the key returned field. Pagination behavior is the main omission, but nothing critical for correct invocation is missing.

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

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

Schema description coverage is 100%, so query, platform, and workspaceId are already documented in the schema. The description only hints at the workspaceId behavior via 'by default' and adds no syntax or format detail beyond the schema; baseline 3 applies.

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

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

States a specific verb (List) and resource (connected social media accounts) with explicit scope ('across every authorized workspace by default'). An agent can immediately distinguish this from list_workspaces or list_media, which operate on different resources, without opening any schema.

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

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

Gives a concrete downstream usage rule: 'Use the returned account ID for publishing so the workspace is resolved automatically,' which ties this tool to the publish workflow. The word 'by default' signals that results can be narrowed, implying when to pass workspaceId, but no siblings are named and no explicit exclusions 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description usefully adds that results span every authorized workspace unless constrained, plus cursor-based pagination — context a caller cannot get from the annotations. Ordering and rate limits remain undisclosed.

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

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

A single sentence with the resource first and the scoping/pagination behavior trailing — front-loaded and free of filler. It is dense but every clause carries information.

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

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

For a no-required-parameter list tool with full schema coverage, no output schema, and complete annotations, the description supplies the two things structured fields omit: default cross-workspace scope and pagination style. Return field details are absent but no output schema exists to demand them.

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 limit, cursor, and workspaceId are already documented, including ranges and the default of 20. The description adds only the semantic that workspaceId is a narrowing filter over an otherwise cross-workspace result set, which is mild added value over the schema.

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

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

States a specific verb and resource ('List uploaded media') and adds a scope qualifier ('across every authorized workspace by default'), which cleanly separates it from delete_media and the post/account/workspace listers. It does not name a sibling alternative explicitly, so it stops short of the top tier.

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 statement of when to reach for this tool versus list_posts, list_accounts, or list_workspaces, and no exclusions or prerequisites. The only conditional ('by default') describes scope behavior, not selection guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the auth scope ('Requires analytics:read') and a return-behavior note ('Returns posts with available analytics'), which is real value beyond structured fields, though pagination and partial-result semantics are left implicit.

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 scope, with no filler. Efficient, though the ordering buries the auth requirement after the return note rather than grouping prerequisites.

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?

An output schema exists, so return values need not be described, and annotations cover safety. However, for a 14-parameter analytics tool with multiple overlapping filter groups, the description does not explain how the filters interact or when the workspace/account identifiers matter, leaving the agent to reconstruct behavior from the schema alone.

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

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

Schema coverage is only 50% across 14 parameters, and the description compensates for almost none of the gap: it gestures at sortBy ('sorted by a supported performance metric') but says nothing about days vs. startDate/endDate, cursor, accountId vs. accountIds, groupId, comparison, or includeSeries. The undocumented half of the surface stays undocumented.

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 analytics for posts published through dopost') plus a qualifying behavior (sorted by a supported performance metric). It is clear what the tool does, but it never distinguishes itself from the closely-named sibling get_post_performance or from get_analytics_overview, so the agent must infer that this is the bulk/list variant.

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

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

The description supplies a prerequisite ('Requires analytics:read') but gives no when-to-use guidance against get_post_performance, get_analytics_overview, or get_content_insights. Usage is only implied by the plural 'List' framing and the sort/filter surface.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds the genuinely useful default-scope behavior (all authorized workspaces unless narrowed), but says nothing about result ordering, page size defaults, or what an exhausted cursor returns. Adequate but thin beyond annotations.

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

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

Two short sentences with the most important fact (default scope) front-loaded and zero filler. Slightly terse relative to what a list tool could convey, 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?

For a 4-parameter, zero-required read tool with full schema coverage, complete annotations, and no output schema, the description covers scope, filtering, and pagination. The remaining gap (ordering and result shape) is minor and partly excused by the absence of an output schema requirement.

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 limit, cursor, status, and workspaceId. The description only restates status filtering and cursor pagination without adding format, default, or interaction details, so the baseline 3 applies.

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

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

States a specific verb and resource ('List posts') plus the default scope ('across every authorized workspace'), which is meaningful detail. It does not explicitly differentiate itself from siblings like get_post or list_post_performance, but the collection-vs-single distinction is implied by the verb.

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

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

Usage is implied: the description notes the default all-workspace scope and that filtering by status and cursor paging are supported, hinting that workspaceId narrows results. However, there is no explicit when-to-use/when-not guidance and no named alternative (e.g., get_post for a single post).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds that results include schedule, accounts, next run, and latest result, which is genuinely useful context, but says nothing about pagination, result limits, or how paused/completed series behave.

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 that leads with the verb and resource and then enumerates the returned data; nothing is wasted. It is slightly list-like but each element is informative.

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

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

With no output schema, the description is the only source of return-value information and it does name the returned fields, which helps. However, it omits result-count defaults, pagination, and sorting behavior that an agent listing potentially many recurring series would need.

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

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

Schema coverage is 100% and both parameters are documented in the schema (status enum, workspaceId). The description adds no syntax, defaults, or combination semantics beyond what the schema already states, so the baseline of 3 applies.

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

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

The description gives a specific verb ('List') and a precise resource ('recurring post series'), plus the fields returned (status, schedule, accounts, next run, latest result). This clearly separates it from create_recurring_post and update_recurring_post, though it never names a sibling 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?

There is no guidance on when to use this tool versus list_posts, get_post, or the other listing siblings, and no mention of prerequisites or filter defaults. Usage is only inferable from the tool 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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description still adds value by disclosing that results are permission-scoped ('every workspace this connection can currently access') and by enumerating the returned metadata fields, which annotations 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?

Two sentences, zero filler, with the returned-field list and the usage restriction each doing distinct work. The most decision-relevant information (what it returns) is front-loaded before the routing caveat.

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

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

For a zero-parameter, annotated, read-only list tool with no output schema, the description supplies everything an agent needs: scope of results, returned fields, and the condition under which calling it is warranted. 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?

The tool takes zero parameters, so the baseline is 4. The description correctly implies no filtering or pagination inputs are needed ('List every workspace'), which is consistent with the empty schema.

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

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

States a specific verb ('List') and resource ('workspace'), and enumerates what each entry contains (names, slugs, roles, timezone metadata). It also distinguishes its scope from adjacent sibling list_accounts by noting that resource and account IDs resolve their own workspace, so the agent can tell this is the workspace-level enumerator rather than an account-level one.

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-to-use condition ('only when a workspace-wide operation is ambiguous') and a when-not condition (resource and account IDs resolve their workspace automatically). It does not name a specific alternative tool, which keeps it just short of a full 5, but the usage boundary is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral guidance beyond that: names are the user-facing value and communityId is an internal fallback used only when names are ambiguous.

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

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

Three sentences, purpose front-loaded, and each sentence carries usable information. The third sentence is dense but earns its place by linking this tool to publish_post usage.

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?

An output schema exists, so return values need not be explained. For a simple single-parameter list tool, the description covers purpose, user-facing handling, and downstream integration completely.

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

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

With 100% schema coverage and a single parameter, the schema already documents accountId fully. The description reinforces the 'one connected X account' scoping but adds no syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource ('List the Communities saved for one connected X account'), scoping it to a single account. It is clearly distinguishable from add_x_community and remove_x_community in the sibling list.

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

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

Gives clear downstream context: present names to the user, then pass the selected name via publish_post platformOptions.communityName. It routes the agent toward publish_post without stating explicit when-not conditions, 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 readOnly, idempotent, openWorld and non-destructive, but the description adds genuinely new behavioral facts: the URL is temporary, no binary data is pulled into the conversation, and no API key is required. It still omits how long the URL stays valid, which would matter for a temporary artifact.

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 the capability before the behavioral caveats, and no filler. The closing clause about the API key is the weakest sentence but still conveys auth context.

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?

An output schema exists, so return values need no explanation, and the description covers format, quality, fallback behavior and the no-binary-download guarantee. What is missing is the link to get_social_media_download_options for discovering supported options and any note on URL lifetime.

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 explains url, format, quality and audioBitrateKbps, including examples and ranges. The description only restates the format choice and adds the fallback rule, which is a modest supplement to an already-complete schema, so the baseline of 3 applies.

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

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

States a specific verb (prepare) and resource (one temporary download URL) and scopes it to public YouTube, Instagram, or TikTok media, so the agent knows exactly what it produces. It does not distinguish itself from the sibling get_social_media_download_options, which is the most likely point of confusion, so it falls short of a 5.

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

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

Usage is implied by the platform and format scoping, and the quality-fallback sentence tells the agent what happens when the exact quality is unavailable. However, there is no explicit when-to-use/when-not guidance and no pointer to the related get_social_media_download_options sibling for discovering valid options.

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

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

Beyond the annotations (destructive, non-idempotent, open-world), the description discloses atomicity ('every account is validated before any post is created'), single-import of shared media, file verification on receipt versus destination checks at publish time, and that incomplete drafts are allowed. It also explains that a processing response is only an acceptance, which is critical for an async mutation. It does not spell out what a destructive failure leaves behind or how partial failures across accounts are reported, so it stops short of a 5.

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

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

The purpose is front-loaded and the prerequisite (get_platform_limits) follows immediately, which is good ordering. However, the block is dense and mixes several registers in one paragraph, repeating draft/publishAt semantics that the schema already states, and the section on media metadata sits awkwardly among publish-flow rules.

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 10-parameter, multi-destination mutation tool with no output schema, the description covers prerequisites, validation order, draft behavior, scheduling semantics, and async result confirmation. What it omits is the shape of the accepted/processing response and how per-account failures surface across a group of up to 20 accounts.

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

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

With only 50% schema coverage, the description carries real weight: it clarifies accountId vs posts as alternatives, that item fields replace top-level defaults, that drafts omit publishAt, and which platforms accept thread and replyTo. Gaps remain for timezone handling and for how platformOptions keys map to destinations beyond 'see parameter description for details'.

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

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

The opening sentence names the specific verb set (publish, schedule, save draft, reply, thread) and the resource, so the agent immediately knows this is the multi-mode creation tool. It is clearly separable from siblings like create_recurring_post, reschedule_post, and get_post, which are named or implied by the follow-up instructions.

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 explicit conditional routing: 'Before publishing or scheduling (draft is false or omitted), call get_platform_limits', draft=true versus publishAt for scheduling, accountId for one account versus posts for a group, and thread/replyTo only for named platforms. It also states the alternative path when a processing response is returned (use get_post to confirm PUBLISHED or inspect FAILED).

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: removal is scoped to the saved catalog (not the community itself) and a user confirmation is required. It does not state reversibility or whether the community can be re-added.

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

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

Three sentences, each carrying distinct information: what is removed and from where, the parameter preference, and the safety gate. The scope is front-loaded 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?

Output schema exists, so return values need not be described. For a destructive mutation, the description covers scope, parameter selection, and the confirmation precondition, and annotations cover idempotency and destructiveness. Nothing essential to correct invocation is missing.

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

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

Schema description coverage is 100%, so baseline would be 3, but the description adds real semantic value by specifying a preference ordering between communityName and communityId that the schema descriptions do not express. accountId's source (list_accounts) is already in the schema.

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

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

Names a specific verb (Remove) and a specific resource (a Community) with scope narrowed to one connected X account's saved catalog. This clearly distinguishes it from the sibling add_x_community, and an agent can tell what it does without opening the schema.

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

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

Explicitly states which parameter to prefer (communityName) and the narrow condition for the fallback (communityId only on name collisions), plus a confirmation gate before calling. It does not name sibling alternatives such as add_x_community, but the operational guidance is concrete rather than implied.

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

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

Annotations already flag destructive=false... actually destructiveHint=true, idempotentHint=false, openWorldHint=true, so the safety profile is documented. The description adds genuine behavioral context beyond annotations: the PENDING-only precondition and the consequence that the post auto-publishes at the new time. It doesn't say what error results from a non-pending post, so not a 5.

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

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

Three tight sentences, front-loaded with the action, followed by the precondition and a warning. Every sentence earns its place with no 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, the description does not need to explain returns, and annotations cover the safety profile. It equips the agent with the key precondition and the auto-publish consequence, though it omits what happens on failure (error vs no-op), leaving one minor gap.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds no format or syntax detail about postId, publishAt, or timezone beyond what the schema already states, so it neither compensates nor detracts.

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: 'Replace the delivery time of a pending post.' This clearly differentiates it from siblings like update_recurring_post, publish_post, and delete_post. An agent can identify the operation without opening the schema.

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

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

Gives a clear precondition ('Only works on posts with status PENDING') which implicitly defines when-not-to-use, and adds a caution to confirm the post and time before calling. It does not explicitly name alternative tools (e.g. update_recurring_post for recurring posts), 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 destructiveHint=true and idempotentHint=false, so the mutation/non-idempotent nature is known. The description adds real value beyond that: it warns that future occurrences publish automatically and urges confirming replacement values, plus the two-minute startsAt lead-time rule. This is solid behavioral context, though it does not clarify partial-vs-full replacement semantics.

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

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

Two sentences, no padding, and the core action is front-loaded before the constraints. Every clause (mutable facets, startsAt rule, auto-publish warning) 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 update tool with a rich nested schema and no output schema, the description covers the essential behaviors: what is replaced, the timing constraint, and the auto-publish consequence. The main remaining gap is not distinguishing partial updates from full replacement, but the coverage is otherwise sufficient.

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

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

Schema description coverage is low (36%), so the description carries some burden. It clarifies only the startsAt constraint (at least two minutes in the future); the other parameters, including the recurrence fields (endType, occurrenceCount, weekdays, interval), get no explanatory help beyond the schema. The nested platformOptions object is self-documented, which keeps this at baseline.

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

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

The description names a specific verb ('Replace') and enumerates the mutable facets of a recurring series (next occurrence, recurrence rules, content, media, platform options). This clearly distinguishes it from create_recurring_post and manage-only siblings like list_recurring_posts, though it does not name those siblings explicitly.

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

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

It scopes the target ('active or paused recurring series') and gives a precondition for startsAt, which is useful context. However it never states when to prefer this over alternatives such as reschedule_post, so usage is only implied rather than guided.

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