BulkPublish

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

Annotation contradiction: the description says the tool 'frees stored parts' and aborts an upload, which is a destructive/irreversible operation, while the annotation declares destructiveHint=false. This directly contradicts the described behavior and could mislead an agent about the operation's safety.

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 short and front-loaded with the action and effect. There is minor redundancy between 'free its stored parts' and 'its stored parts freed', but no real padding exists.

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

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

For a simple two-parameter operation with complete schema coverage, the description covers what the tool does and when to use it. However, the destructiveHint=false annotation contradicts the stated cleanup behavior, undermining the agent's ability to reason about side effects; no output schema is present, so return-value details are not required.

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, and each parameter is documented as the value returned by create_multipart_upload. The description itself adds no additional parameter semantics, so 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 uses a specific verb ('Abort') and resource ('in-progress chunked upload') and states the concrete effect ('free its stored parts'). This clearly distinguishes it from sibling tools like create_multipart_upload and complete_multipart_upload.

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

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

The description explicitly says 'Use this when a chunked upload should be cancelled and its stored parts freed.' It gives a clear condition for use, though it does not explicitly mention when not to use it or name alternatives; cancellation is a distinct action with no true sibling alternative.

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

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

The description reveals concrete behavioral effects beyond the annotations: releasing a pending post, scheduling publication (immediate if time passed), notifying the author, and specific error codes (400, 403, 404). The annotations only state readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the description carries the full burden and exceeds it.

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 well-structured: purpose is first, followed by role requirement, behavioral effects, errors, and usage guidance. Each sentence adds useful information, though the final 'Use this when...' sentence largely restates the opening purpose, creating minor 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 a single parameter, rich annotations, and no output schema, the description provides everything needed to call the tool correctly: prerequisites, side effects, error conditions, and clear usage context. Nothing essential is missing.

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

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

The input schema already describes postId as 'The post ID to approve.' with 100% coverage, so the description adds no new parameter-level information. Baseline 3 applies because the schema fully handles parameter semantics; the description only implies the param by referencing the post being approved.

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 ('Approve'), a specific resource ('a post awaiting team approval'), and the condition that defines that resource (approvalStatus 'pending'). It distinguishes itself from siblings like publish_post, reject_post, and update_post by focusing on the approval workflow rather than immediate publishing or editing.

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

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

The description explicitly states when to use the tool: 'Use this when the user (an owner/admin/approver) wants to approve a post awaiting team approval.' It also details the required role and the conditions under which errors occur, effectively excluding cases where the post is not pending or the user lacks permission.

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, covering the mutation risk. The description adds that operations affect multiple posts at once, but doesn't disclose consequences like irreversibility of deletes or partial-failure behavior. It stays consistent with annotations without adding much beyond them.

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

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

Two tight sentences: the first states the purpose and actions, the second states usage. No wasted words and the key information is front-loaded.

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

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

For a bulk destructive operation, the description covers purpose, when to use, and the action set, and the schema documents all parameters. It would benefit from a note about return format or partial-failure handling, but the essentials for invoking the tool correctly are present.

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%: action's enum, postIds, and scheduledAt each have descriptions in the schema. The tool description adds no extra parameter semantics, so it meets the baseline for fully documented schemas.

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

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

The description clearly states the resource ('multiple posts') and the specific verb ('Perform a bulk action'), then enumerates the supported actions (delete, retry, reschedule). It distinguishes itself from sibling single-post tools by emphasizing 'many posts in a single request'.

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

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

The second sentence gives an explicit when-to-use trigger: 'Use this when the user wants to delete, retry, or reschedule many posts in a single request.' However, it doesn't explicitly mention single-post alternatives or exclusions, so it's clear but not fully complete.

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

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

The description discloses substantial behavior beyond the sparse annotations: server-side assembly, verification of existence, size, magic bytes and storage quota, recording the media file, and automatic abort on failed assembly. This gives the agent a realistic picture of side effects and failure modes.

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

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

The description is two sentences long, front-loads the action, and each clause adds meaningful information: process, verification, response similarity, failure behavior, and invocation condition. There is no filler.

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

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

For a complex 9-parameter operation with no output schema, the description covers the workflow, verification, and side effects. The only mild gap is that 'same verification and response shape as finalize_media_upload' defers detail to another tool's definition, but the behavior described is otherwise self-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 100%, so the schema already documents all parameters and their meanings. The description adds little beyond the schema, except implicitly reinforcing that parts carry ETags collected from PUT requests.

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: 'Complete a chunked upload' and explains the assembly, verification, and media-file recording process. It also references finalize_media_upload, which helps position this tool relative to a closely related sibling.

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

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

It explicitly says 'Use this when all parts of a chunked upload are PUT and their ETags collected,' giving a clear condition for invocation. It does not explicitly state when not to use it or name a non-chunked alternative, but the guidance is sufficient for typical 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 signal readOnlyHint=false and openWorldHint=true, so mutation is expected. The description adds valuable behavioral context beyond that: it opens a UI, shows connected channels, pre-fills provided text, and creates the post via create_post only on submit.

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

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

Three sentences, each earning its place: the primary behavior, the UI interaction details, and the usage guidance with an alternative. 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?

With one optional parameter, an output schema present, and annotations covering the safety profile, the description is complete enough for invocation. The decision rule and delegation-to-create_post note fill the remaining context.

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 content as 'Optional initial text to pre-fill the composer with.' The description's 'pre-fills any provided text' adds little beyond the schema, so the 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?

States a specific verb ('Open an interactive composer') and resource ('social media post'), and explicitly contrasts itself with create_post by distinguishing interactive UI composition from direct creation. It clearly differentiates this tool from its 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 an explicit when-to-use rule: 'Use this when the user wants to compose a post interactively in a UI' and names the alternative, create_post, with the deciding condition 'when they'd review before posting.' This is direct decision 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?

It adds meaningful behavior beyond the annotations: names are unique per organization, duplicates fail with 409 and code DUPLICATE_NAME, and there is a 50-set cap. These are exactly the edge constraints an agent needs to anticipate. It does not mention auth or success response, but for a simple create operation the key behaviors are covered.

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 with no filler. The purpose is stated first, followed by critical constraints, then the explicit usage trigger. Every sentence earns its place.

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

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

For a simple two-parameter create tool without an output schema, this description is nearly complete. It covers purpose, constraints, failure behavior, and when to use it. It does not describe the expected success response, but that is not essential for correctly invoking the 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 100%, and the schema already documents both parameters well. The description adds a bit of context around uniqueness and organizational scope, but it does not substantially extend what an agent already learns from the input schema.

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

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

The description opens with a clear action and resource ('Create a channel set') and defines what that resource is: a saved channel grouping for one-click multi-channel targeting. This distinguishes it from list_channel_sets, update_channel_set, and delete_channel_set by verb and concept.

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

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

It explicitly states when to use the tool: 'Use this when the user wants to save a group of channels for one-click targeting.' It does not explicitly contrast with update/list/delete siblings, but the use-case guidance is clear enough for an agent to select it correctly.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, implying a non-destructive write operation. The description adds that it is 'for organizing posts or media files', which provides some context, but it does not disclose potential side effects (e.g., whether the label is immediately usable, any ownership constraints, or if names must be unique). Given minimal annotation coverage, the description partially carries the burden but lacks deeper behavioral detail.

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

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

Two sentences with no filler. The core action is front-loaded ('Create a new label'), and the second sentence immediately offers usage guidance. Every word 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 simple creation tool with three parameters fully documented in the schema and no output schema, the description covers the what and when adequately. It could mention that the operation returns the created label or confirm success, but since no output schema exists and the tool is straightforward, the description is sufficiently complete. It does not explain any prerequisites or error conditions, though these are not strictly required.

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 input schema already documents all three parameters (name, type, color) with descriptions and defaults. The tool description adds no parameter-specific information. Baseline of 3 is appropriate when the schema fully covers parameter semantics.

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

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

The description states a specific verb and resource ('Create a new label'), and clarifies the domain ('for organizing posts or media files'), which distinguishes it from sibling tools like update_label and delete_label. The explicit use-case statement ('Use this when the user wants a new label/tag') reinforces its purpose.

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

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

The description provides clear when-to-use guidance ('Use this when the user wants a new label/tag'). It does not explicitly name alternative tools (e.g., update_label, delete_label), but the phrase 'new label' implies a creation context, making it adequate without being 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 only carry readOnlyHint=false and destructiveHint=false, so the description does most of the work. It adds genuinely useful behavior context—this tool reserves a URL rather than transferring the file itself. But it omits consequential traits: presigned URL expiration, whether finalize_media_upload must follow, and what happens to an unused reservation.

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

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

Two sentences with the core purpose front-loaded. The second sentence is redundant—'Use this when you need a presigned URL for a large direct upload' restates the reservation concept, and 'prefer upload_media for normal files' duplicates 'For scripted uploads use upload_media instead'—so it could be tightened without losing 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 leaves the return value undescribed, even though the presigned URL (and any reservation ID or expiration) is the entire point of the call. The multi-step flow is also incomplete: the finalize_media_upload sibling suggests a follow-up step that the agent is never told about. For a 2-param tool this is adequate but not 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 coverage is 100%: both sizeBytes and contentType have descriptive text in the input schema. The description adds no parameter-level meaning (no size limits, no allowed MIME types, no constraints), so the baseline 3 applies with the schema doing 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: 'Reserve a presigned R2 upload URL' for a 'direct browser upload,' and anchors it to the composer UI. It explicitly distinguishes from the nearest sibling by adding 'For scripted uploads use upload_media instead,' so an agent can tell this tool apart without opening either schema.

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

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

Gives an explicit when-to-use ('Use this when you need a presigned URL for a large direct upload') and an explicit exclusion ('prefer upload_media for normal files'). However, it never addresses the multipart upload siblings (create_multipart_upload, finalize_media_upload), so an agent has no guidance on when the multipart flow should be chosen instead.

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 indicate readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining behavior. It does this well by disclosing that the tool returns r2Key, uploadId, a fixed partSize, and presigned URLs valid for 3600s, and that the caller must PUT chunks, collect ETags, and call complete_multipart_upload. It does not mention abort_multipart_upload as a cleanup option, which is a minor gap.

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

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

The description is well-structured and front-loaded with the tool's purpose, then return values, then the workflow, then when-to-use guidance. It is slightly repetitive about the 1GB/100MB limits, appearing both at the start and end, but every sentence otherwise 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 two-parameter tool with no output schema, the description is complete enough for an agent to invoke it and continue the next step. It names the returned fields, the chunk size, URL validity, the required PUT/ETag flow, and the follow-up call to complete_multipart_upload. Nothing essential to calling this tool is missing.

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

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

Schema description coverage is 100%, so the schema already fully documents sizeBytes and contentType. The description reinforces the size limits and introduces partSize, but does not add substantial parameter meaning beyond the schema. 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 uses a specific verb ('Start') and resource ('chunked (multipart) direct-to-storage upload') and immediately distinguishes it from ordinary uploads by size and chunking. It also names sibling tools like complete_multipart_upload and upload_media, which removes 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?

The description gives explicit when-to-use guidance: 'Use this when a file is too large for a single upload (e.g. a video over 100MB, up to 1GB) and must be sent in 10MB chunks.' It also explicitly prefers upload_media for ordinary files, giving a clear alternative and condition for choosing this tool instead.

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 are minimal (not read-only, not destructive), so the description carries the behavioral burden. It discloses that posts can be saved as drafts or scheduled, that publishing is not immediate, and adds critical platform constraints: YouTube/TikTok require video and Instagram defaults to feed_photo requiring postTypeOverrides for video. It omits some behavior like forced approval for contributors, but the schema covers that detail.

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 compact and front-loaded: purpose first, then feature summary, then critical caveats, then usage boundary. Every sentence contributes something an agent needs, with no filler or repetition of obvious schema details.

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

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

For a tool with 14 parameters and deeply nested platform options, the description covers the essential intent, the most consequential platform-specific requirements, and the primary usage boundary. It does not describe the return value despite having no output schema, but the schema thoroughly documents parameter details, so this is a minor gap.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful cross-parameter semantics: it warns that YouTube/TikTok must not be included for image-only posts and that Instagram video content requires postTypeOverrides. This helps the agent select valid parameter combinations beyond what the schema alone 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 clear verb and resource: 'Create a new social media post.' It further scopes the action to 'one new post' that can be drafted or scheduled, which distinguishes it from publishing or bulk-creation siblings. The final sentence explicitly says it is for drafting/scheduling, not immediate publishing.

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 an explicit usage directive: 'Use this when the user wants to draft or schedule one new post (do not publish immediately unless asked).' This makes the primary use case clear, though it does not name or exclude alternatives like compose_post or bulk_posts.

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

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

The description adds substantial behavioral facts beyond the sparse annotations: the feed is polled every 15 minutes, the server validates reachability of the feed URL, and the organization has a hard limit of 20 feeds. These are all behaviors an agent needs to set expectations and anticipate failures.

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 concise sentences, each carrying distinct information: core purpose, polling behavior, validation/quota, and usage guidance. Information 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?

For a complex create operation with six parameters and nested objects, the description covers selection, polling cadence, validation, and quota. It does not describe the response shape, and since there is no output schema, that leaves a minor gap for an agent wanting to know what a successful create 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%, so the baseline is 3. The description adds value by explaining that feedUrl is server-validated as a reachable public feed and that channelIds receive the generated posts. This supplements the schema's already solid parameter descriptions without fully covering every nested option.

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

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

The description opens with a specific verb and resource: 'Add an RSS autopost feed.' It clearly explains what the tool does — creates a feed that is polled every 15 minutes and turns new items into posts — and closes with a usage statement that disambiguates it from manual post creation tools like create_post or compose_post.

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

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

It explicitly says 'Use this when the user wants new items from an RSS/Atom feed to become posts automatically,' which gives a clear trigger condition. It does not name explicit alternatives to avoid, nor state when not to use it, 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 only provide readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden. It discloses automatic creation and publishing, visibility in the web app, and the key lifecycle detail that a post record exists only after an occurrence fires. This goes well beyond the annotations.

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

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

Three compact sentences, front-loaded with the core purpose, followed by lifecycle/visibility context and a clear usage cue. Every sentence earns its place, with no filler or redundant schema repetition.

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

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

For a complex 11-parameter create tool, the description covers the key conceptual model: when posts appear, where the schedule is visible, and the recurringScheduleId link to generated posts. It is slightly incomplete because there is no output schema and the description does not state what the create call returns, but schema coverage compensates for most invocation details.

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 parameters are already fully documented. The description adds no parameter-specific semantics and instead focuses on tool behavior, which is appropriate. The baseline of 3 applies because the schema does the heavy lifting.

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

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

The description states a specific action ('Create a new recurring post schedule') and clearly distinguishes this tool from one-off post creation by explaining that posts are materialized only when an occurrence fires. This differentiates it from sibling tools like create_post and bulk_posts without requiring the agent to open 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?

The description explicitly says 'Use this when the user wants a recurring posting schedule,' giving a clear selection trigger. It does not explicitly contrast this with alternatives like create_post for one-off posts, so it stops short of full 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 indicate destructive and idempotent behavior. The description adds a crucial behavioral detail beyond annotations: deleting the set does not affect the channels themselves. This prevents an agent from assuming cascading deletion, which is valuable context.

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

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

The description is two concise sentences with no filler. The core action is front-loaded, followed by the clarifying scope caveat and a direct usage instruction. Every sentence contributes meaningful guidance.

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 delete operation, the description covers what is deleted, what is not deleted, and when to use it. Combined with annotations for destructive and idempotent behavior, nothing essential is missing for an agent to invoke this tool correctly.

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

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

Schema coverage is 100% and the single parameter setId is already described as 'The channel set ID to delete.' The description adds no additional semantic value beyond restating that deletion occurs by ID, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource: 'Delete a channel set by ID.' It further disambiguates by clarifying that channels themselves are unaffected, distinguishing this from tools that delete actual channels or media. The title and description align clearly.

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

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

The description explicitly says 'Use this when the user wants to remove a saved channel set,' providing clear context for when this tool is appropriate. It does not explicitly discuss exclusions or alternative tools, so it falls just short of top-tier 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 signal destructive and idempotent behavior. The description adds useful beyond-annotation context by revealing the cascade effect: deleting the label removes it from associated posts or media rather than deleting those posts/media. No contradiction with annotations.

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

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

Two short sentences that are front-loaded: the primary action and scope appear first, and the usage guidance follows. There is no filler or redundant elaboration.

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 delete operation, the description covers the action, the cascade effect, and the triggering user intent. It doesn't discuss permissions or response behavior, but the annotations and simple schema make the tool easy to invoke correctly without those details.

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

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

The schema already provides 100% coverage for the single parameter, labelId, with type and description. The description's 'by ID' phrase reinforces this but adds no new semantic detail beyond the schema.

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

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

Clearly states the action ('Delete'), the target ('label by ID'), and the operational effect ('removes the label from all associated posts or media'). This distinguishes it from sibling tools like delete_post, delete_media, and delete_rss_feed, which target 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?

Provides explicit context: 'Use this when the user wants to delete a label.' It does not spell out when not to use this tool or how it differs from update_label/list_labels, but for a simple delete operation the stated intent is sufficient.

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

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

Annotations already carry readOnlyHint=false, destructiveHint=true, and idempotentHint=true. The description adds value by disclosing that the file is removed from storage and detached from any posts, giving an agent a concrete picture of the destructive side effects without contradicting 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 short sentences each serve a distinct purpose: state the primary action, describe the side effect, and give the triggering user intent. There is no filler or tangential detail.

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

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

For a simple, single-parameter destructive operation with complete schema coverage and annotations, the description covers the essential behavior and consequence. It could mention permanence or permissions, but nothing critical is missing 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?

The input schema covers the only parameter (mediaId) with a clear description, and the tool description merely reinforces 'by ID'. With 100% schema description coverage, the description does not need to add much parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description names the exact operation ('Delete a media file by ID') and the resource, and goes beyond the title by specifying the concrete side effect: removal from storage and detachment from posts. This clearly distinguishes it from sibling delete tools like delete_post and delete_label.

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 final sentence explicitly says to use the tool when the user wants to delete a media file, which is a clear usage context. It stops short of naming alternatives or stating when not to use it, but given the sibling set, the intended use case 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 indicate destructiveness (destructiveHint: true) and non-read-only behavior. The description adds valuable context beyond annotations: deletion is permanent and limited to draft/failed posts. This is exactly the kind of state-dependent behavior an agent needs to know before invoking.

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 core action, then the key precondition and usage trigger. Every phrase earns its place; there is no redundancy or 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 simple one-parameter delete operation with destructive and idempotent annotations, the description covers what, when, and under what conditions. No output schema exists, so omitting return details is acceptable. An agent has everything it needs to select and invoke this tool correctly.

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

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

The input schema already documents postId with 100% coverage, so the description does not need to add much. The phrase 'by ID' reinforces the parameter's role but adds no new semantic detail beyond the schema. Baseline of 3 is appropriate given full schema coverage.

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

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

The description uses a specific verb ('Delete'), names the resource ('a post'), and specifies the identifier ('by ID'). It also distinguishes the tool from post-related siblings by stating the deletion precondition (draft/failed only), making its purpose unambiguous.

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

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

The description explicitly says when to use the tool: when the user wants to permanently remove a post. It also imposes a clear eligibility condition ('Only draft and failed posts can be deleted'), which helps agents avoid invalid calls. It does not explicitly name alternative tools for other states, but the guidance is sufficient for the common case.

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 indicate destructive and idempotent behavior, so the bar is lower. The description adds valuable specifics beyond annotations: it stops polling and preserves already-created posts. This gives the agent a more concrete model of the operation's side effects.

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, each earning its place: the first states the action precisely, the second adds key behavioral consequences and use context. 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?

For a single-parameter delete operation, the description covers what is deleted, side effects, and when to use it. Annotations cover destructive and idempotent traits, and no output schema exists, so no return-value explanation is required. Nothing essential is missing.

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

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

Schema description coverage is 100%, and the only parameter, feedId, is already documented as 'The RSS feed ID to delete.' The description adds 'by ID' but no meaningful semantic detail beyond what the schema provides, so 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 uses a specific verb ('Delete') and resource ('RSS autopost feed by ID'), clearly distinguishing it from sibling tools like create_rss_feed, update_rss_feed, and list_rss_feeds. The subject and scope are immediately unambiguous.

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

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

The description explicitly states when to use the tool: when the user wants to stop and remove an RSS autopost feed. It also clarifies that already-created posts are kept, which implicitly distinguishes this from deleting posts. It does not explicitly name alternative sibling tools or when-not conditions, but the guidance is clear enough.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true. The description adds useful behavioral context by stating that the operation 'Stops all future posts from this schedule,' which is a concrete consequence not present in the schema or annotations.

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

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

The description is compact and front-loaded with the core action and target. Each sentence adds value: what it does, the behavioral consequence, and when to use it. 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?

For a single-parameter deletion tool with annotations already covering the destructive and idempotent nature, the description is complete. It names the parameter, describes the effect, and gives usage guidance. No output schema is needed for such a simple operation.

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

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

The schema covers 100% of the parameters, including a description for scheduleId. The tool description does not add much semantic detail beyond what the schema already provides, so a baseline score is appropriate.

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

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

The description clearly states the action ('Delete') and the target resource ('recurring schedule') and specifies that deletion is by ID. It also distinguishes itself from sibling schedule tools like create_schedule and update_schedule by focusing on deletion.

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

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

The description explicitly says when to use the tool: 'Use this when the user wants to stop and delete a recurring schedule.' It does not mention when not to use it or name alternatives, but the usage context is clear enough for accurate selection.

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 signal this is a mutating operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds useful lifecycle context about the browser PUT and composer UI, but it does not disclose potential side effects, idempotency, required auth, or what the response contains, which would further help an agent reason about 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 sentences, front-loaded with the primary action and lifecycle context, then the usage condition. Every clause earns its place with no redundancy or 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?

The tool is a mutation with no output schema, and the description covers the essential precondition and workflow context. However, it does not specify what the call returns (e.g., a media ID or status), which is a meaningful gap when no output schema is present. For an advanced internal composer tool, the existing guidance is serviceable but not 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?

Schema description coverage is 100%, so the schema already explains all seven parameters including that r2Key comes from create_media_upload. The description offers no additional parameter-level meaning beyond the schema, so the 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 clearly states the action ('Record an uploaded R2 object as a media file') and provides sequencing context that distinguishes it from create_media_upload. It positions this as the finalization step after a browser PUT, making the tool's role unambiguous.

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

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

The description explicitly says when to use this tool: 'Use this when a presigned direct upload finished and the file must be registered.' It also notes the pairing with create_media_upload and marks the tool as advanced, giving meaningful routing context even though it doesn't enumerate exclusions or alternatives in detail.

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 mark this read-only and non-destructive; the description adds the concrete return shape (total posts, status breakdown, per-platform stats, daily counts), which is useful because there is no output schema. No hidden side effects or performance caveats are disclosed, but none are strongly expected for a read-only analytics summary.

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

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

Two sentences with no filler; the action and scope are stated first, then the return payload and usage context. Every sentence earns its place.

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

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

For a simple read-only tool with two documented params, the description covers what it returns and when to use it. It could be more complete by distinguishing from get_post_metrics or view_analytics, but nothing required for a correct call is missing.

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

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

Schema covers both parameters 100%, and the description only restates that it is a date range. The schema's ISO format examples carry the semantic weight, so the description adds no parameter-level detail beyond the baseline.

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

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

Names a specific resource ('analytics summary') and scope (date range, overall across channels) with an explicit verb. It does not name or contrast siblings such as get_post_metrics or view_analytics, so differentiation relies on the 'overall' phrasing.

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 condition: when the user asks about overall content performance across channels over a date range. It does not state exclusions or explicitly name alternatives, but the intended context is unambiguous.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral context by specifying exactly what health information is returned, including token validity, connection status, and any issues.

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 no filler. The primary purpose is stated first, the return payload comes second, and the usage trigger is front-loaded and actionable.

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

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

The tool has one parameter, which is fully documented in the schema, and the description explains both purpose and return contents. No output schema exists, but the description adequately covers what the agent needs to know 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% because channelId has a clear description. The tool description does not add meaning beyond the schema, but the schema already carries the full semantic burden, 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 states a specific verb and resource: check the health status of a connected channel. It also names what it returns (token validity, connection status, issues), which distinguishes it clearly from sibling tools like list_channels or get_channel_options.

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 triggering condition: 'Use this when the user asks whether a channel's connection/token is healthy.' This gives an agent clear guidance on when to select this tool over alternatives.

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

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

The annotations already convey that this is a read-only, non-destructive operation, so the description does not need to repeat that. The description adds useful context about what the options contain (post types, limits, media requirements) but does not disclose output format, error behavior, or what happens for an invalid channelId. This is acceptable but not rich behavioral 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?

The description is two sentences long, front-loads the core function in the first sentence, and includes a clear usage cue in the second. Every clause adds value without redundancy or 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 simple read-only tool with one well-documented parameter and no output schema, the description is largely complete: it identifies the resource, the context, and examples of return content. It could be slightly stronger by noting that the result is a list or object of options, but the current coverage is adequate for an agent to use the tool correctly.

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

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

Schema description coverage is 100% and the single parameter, channelId, is already described as 'The channel ID to get options for.' The description reinforces that options are platform-specific but does not add significant new meaning beyond the schema. A baseline of 3 is appropriate.

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

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

The description clearly states a specific verb ('Get'), a resource ('platform-specific options for a channel'), and concrete examples (post types, character limits, media requirements). It also ties the purpose to a concrete workflow step, which helps an agent distinguish it from sibling tools like get_channel_health or list_channels.

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

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

The description explicitly says to use this tool when you need a platform's valid post types before creating a post, providing clear when-to-use guidance. It does not explicitly name alternatives or state when not to use it, so it stops short of 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 declare readOnlyHint=true and destructiveHint=false, so no safety ambiguity exists. The description adds useful behavioral context by naming exactly what will be returned (metadata, URL, dimensions, labels), which matters because there is no output schema.

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

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

Two sentences, no filler. The action and return summary are front-loaded, and the usage condition is tucked into a short second sentence. Every word 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 single-parameter read-only getter, this is nearly complete: it identifies the input, describes the output, and gives a usage trigger. It does not cover error cases like 'not found,' but those are not essential for tool selection and the annotations handle safety context.

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 mediaId is already described as 'The media file ID.' The description reinforces the ID-based lookup but does not add new semantic details such as format, uniqueness, or lookup behavior 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 ('get'), resource ('single media file'), and selection key ('by ID'), and enumerates returned fields (metadata, URL, dimensions, labels). This clearly distinguishes it from sibling tools like list_media, delete_media, and upload_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?

Provides an explicit when-to-use trigger: 'when the user references one specific media file by ID.' It does not name sibling alternatives or state when not to use it, but the condition is clear enough for straightforward selection.

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 provide readOnlyHint=true and destructiveHint=false, so the safety profile is established. The description adds useful context about the response contents, but doesn't disclose operational behavior such as error handling, permission requirements, or rate limits. This is acceptable for a simple read-by-ID operation.

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

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

The description is two efficient sentences with no filler. The core action and key output contents are front-loaded, and the usage guidance is a separate, clear second sentence.

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

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

For a read-only tool with one required parameter, full schema documentation, annotations, and a description that enumerates the response contents, everything an agent needs to invoke it correctly is present. There is no output schema, but the description compensates by summarizing the response scope.

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

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

The schema fully documents the single parameter postId with 'The post ID.' Since schema description coverage is 100%, the description doesn't need to add parameter details, and it doesn't. This aligns with the baseline for full schema coverage.

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

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

The description clearly states a specific action—'Get a single post by ID'—and defines the scope by listing the types of details returned (platform statuses, labels, media files, recurring schedule info, metrics). This distinguishes it from sibling tools like list_posts and get_post_metrics.

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

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

It explicitly says to use this tool 'when the user references one specific post by its ID,' which gives the agent a clear trigger condition. It doesn't explicitly contrast with sibling tools like get_post_metrics, but the guidance is sufficient for correct selection.

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 mark the tool as read-only and non-destructive, and the description adds substantial behavioral context: unsupported metrics are stored as 0 and must be reported as unavailable, platform-specific metric availability is detailed, linkClicks semantics are clarified, and bot traffic exclusion is mentioned. No contradiction with annotations.

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

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

The description is long but dense with necessary caveats about platform-specific metrics and linkClicks semantics. It front-loads the core purpose and then explains behavioral nuances. Some sentences could be tightened, but the detail 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?

Given the lack of an output schema and the complexity of the return data, the description explains key return fields, platform variations, zero-value semantics, and linkClicks handling. It does not fully describe the root response structure, but enough context is provided for correct invocation and interpretation.

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

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

Schema coverage is 100% for the single postId parameter, so the schema already documents it. The description adds context by referring to 'a published post,' but it does not further explain parameter format or edge cases. 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?

Description clearly identifies the operation: getting engagement metrics for a published post and lists the returned metric types. It does not explicitly differentiate from siblings like get_post or get_analytics, but the 'use this when' clause gives a clear functional boundary.

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

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

Explicitly states when to use the tool: 'Use this when the user asks how a specific post performed (likes, views, engagement).' It does not enumerate alternatives or exclusions, but the guidance is sufficient for a targeted metrics lookup.

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 the safety profile is covered. The description adds minimal behavioral context (e.g., that it returns the next available slot and is tied to scheduling), but does not disclose details like whether it respects existing schedule conflicts or how current time is determined. With annotations covering the main traits, a 3 is appropriate.

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

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

The description is two sentences, directly front-loaded with the core purpose, followed by a usage trigger. There is no filler or repetition. Every sentence earns its place.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description covers what it does and when to use it. It could optionally mention what the return value represents (e.g., a timestamp), but the absence is minor given the tool's simplicity. Overall, an agent can infer how to call it correctly.

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

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

Schema description coverage is 100%: the timezone parameter is fully documented in the schema. The description does not add any parameter semantics beyond what's already in the schema. Baseline 3 is correct when the schema handles parameter documentation.

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: 'Get the organization's next available queue slot.' It also clarifies the intent ('finding the next optimal scheduling time') which distinguishes it from schedule management tools like create_schedule or list_schedules. The purpose is unambiguous and actionable.

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

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

The description explicitly says when to use it: 'Use this when the user asks when the next available scheduling slot is.' This provides clear context. It does not mention alternatives, but no direct sibling exists for this operation, so the omission is acceptable. No exclusions or when-not-to-use is given, but the explicit trigger is sufficient.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description goes beyond that by explaining the channelSlots semantics in detail (pricing, auto-cancelation, effect on channel limits, autoRenews field), which is valuable behavioral/domain context not present in the schema or annotations. It does not disclose any contradictions.

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

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

The description is three sentences, front-loading the core purpose and then detailing the return fields. The detailed channelSlots explanation is dense but earns its place given the complexity of that field. It is appropriately sized for the information conveyed.

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

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

For a zero-parameter, read-only tool with no output schema, the description covers the tool's purpose, the main return categories, the nuanced channelSlots behavior, and the user-intent trigger. Minor omissions like exact response formatting or possible errors are acceptable given the simplicity and the annotations covering safety.

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

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

The input schema has zero properties, so parameter semantics are moot. Per the baseline for 0 parameters, a score of 4 is appropriate; the description correctly implies no arguments are required.

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

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

The description opens with a clear verb-resource pair ('Check current account usage') and enumerates the specific data returned (daily/monthly post counts, scheduled posts, channels, media storage, channelSlots). It is unambiguous about what the tool reports, though it does not explicitly differentiate it from the sibling 'view_quota'.

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 final sentence explicitly states when to use the tool: 'Use this when the user asks about plan limits or current usage.' This gives clear context, though it does not mention alternatives or when not to use it, so it falls 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 mark the operation read-only and non-destructive. The description adds useful behavior context by stating the returned fields (channel ID, platform, account name, token status), which is especially valuable since no output schema is provided. It does not fully reconcile 'all connected' with the active filter defaulting to true, but that is documented in the parameter schema.

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

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

Three tight sentences: what it lists, what it returns, and when to use it. There is no filler, and the action/resource are front-loaded.

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

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

For a one-parameter, read-only list tool with no output schema, the description is nearly complete: it states scope, return fields, and a use case. The only minor gap is not spelling out the active-channel default behavior in the description, but that information is present in the input schema.

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 active parameter already clearly states filtering behavior and default. The tool description adds nothing about the parameter, so it does not go beyond the schema's documentation.

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 action ('List') and resource ('connected social media channels'), enumerates platforms, and lists return fields, so an agent can tell this is the channel-listing tool. It does not explicitly contrast with the similar-looking view_channels sibling, so it falls short of full 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 description provides a clear trigger: 'Use this when the user wants to see which social accounts are connected.' It gives no exclusions or alternative-tool routing, but the context is enough for basic selection.

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

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

The description adds behavior beyond the readOnlyHint/destructiveHint annotations: it reveals the payload fields ('id, name, and channelIds') and ordering ('ordered by name'). For a stateless read-only list with no parameters, this is sufficient transparency; it doesn't discuss pagination or errors, but those are relatively minor.

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

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

Three short sentences each add information: what the resource is, what the response contains, and when to choose the tool. 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?

A zero-parameter read-only list is fully specified by the combination of annotations, the empty schema, and a description that states return shape and ordering. Nothing an agent needs to invoke it correctly is missing.

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

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

There are zero parameters, and the schema coverage is 100%, so the baseline of 4 applies. The description reinforces that the tool takes no inputs simply by being a list operation with no param discussion, and no additional parameter guidance is needed.

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

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

The description opens with a specific verb and resource — 'List saved channel sets' — and defines the resource as 'channel groupings for one-click multi-channel targeting.' It also names the return fields (id, name, and channelIds), which distinguishes it from list_channels and other 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?

'Use this when the user wants their saved channel groups (channel sets)' gives a clear, actionable trigger condition. It does not mention when not to use it or name alternatives like list_channels, so it stops short of 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?

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool lists all labels available for posts and media, but does not add deeper behavioral details such as pagination, ordering, or response shape.

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

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

The description is two concise sentences with no fluff. The core purpose is front-loaded, and the usage guidance is brief but useful.

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

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

For a simple read-only list tool with one optional, fully documented parameter and readOnly annotations, the description is largely sufficient. It lacks an explicit statement of return value shape, but the phrase 'list all labels' implicitly conveys the expected 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 input schema fully documents the only parameter, 'type,' including its enum values and the note that omitting it returns all labels. The description does not add parameter-specific meaning beyond the schema, so the baseline of 3 applies.

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

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

The description clearly states a specific verb and resource: 'List all labels available for tagging posts and media.' It also gives a concrete user-intent cue, 'Use this when the user wants their post labels/tags,' which helps distinguish this from sibling list_* tools like list_schedules or list_channels.

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

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

The description provides a clear usage cue: use it when the user wants their post labels/tags. However, it does not explicitly mention alternatives or when not to use it, though no direct alternative for listing labels exists among the siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds value by noting the list returns metadata, supports search/pagination, and is scoped to uploaded media. It does not disclose additional behavioral details such as pagination shape or auth requirements, but the read-only nature is already covered by annotations.

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

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

Two sentences, front-loaded with the core action, no filler. The first sentence identifies the operation and scope; the second sentence provides return-value highlights and a clear usage condition. Every sentence earns its place.

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

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

Given there is no output schema, the description compensates by naming the return metadata (URLs, dimensions, labels) and mentioning search/pagination. It is complete enough for a simple read-only list operation, though it could add slightly more detail about the paginated response structure or total count behavior, which is only present in the schema's type parameter description.

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 parameters (page, type, limit, search) are already well documented in the schema. The description reinforces that search and pagination are optional, but it does not add meaning beyond the schema—it just repeats the concepts already present.

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 ('List'), identifies the resource ('uploaded media files'), and differentiates itself from sibling tools like get_media (single fetch), upload_media, and delete_media by framing the operation as a filtered, paginated list. It also names the key return fields, so an agent knows exactly what kind of result to expect.

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

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

The description explicitly states when to use the tool: 'Use this when the user wants a list of their uploaded media files.' This provides clear context, though it does not explicitly name alternatives or say when not to use it (e.g., for retrieving a single file, use get_media instead).

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial behavioral context beyond that: it explains platform states ('off', 'connect_off'), their effects on post creation and connections, the fact that disabled platforms remain listed, and the variant gating mechanism (e.g., LinkedIn organization pages). It also mentions error codes and conditions. No contradiction with annotations; this is high-value transparency.

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 longer than typical but earns its length because it covers nuanced platform states, error behaviors, and variant handling. It front-loads the core purpose and usage, then elaborates on edge cases. While a bit dense, every sentence adds essential information for correct tool selection and use. It is well-organized and not 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?

Given the tool's moderate complexity and the absence of an output schema, the description adequately covers the main contextual aspects: what states exist, what errors to expect, and what fields are present (enabled, reason, variants). It does not provide a full return structure, but it hints at the keys. For an agent needing to decide when to call and interpret results, this is sufficient, though a sample response could improve it.

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

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

The tool has zero parameters, and the schema coverage is 100% (since there are no properties to document). According to the rubric, a baseline of 4 applies for 0 params. The description correctly does not attempt to describe parameters because none exist; it focuses on behavior and return context. No additional parameter semantics are needed.

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

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

The description clearly states the tool's purpose: 'List every social platform BulkPublish supports and whether it is currently available.' It uses a specific verb ('list') and resource ('social platform'), and explicitly mentions the key data ('availability'). This distinguishes it from sibling tools like list_channels and list_rss_feeds, which deal with different resource types. No 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?

The description gives explicit when-to-use guidance: 'Check this before telling a user they can connect a platform or scheduling a post to one' and 'Use this when the user asks which platforms are supported or available, or a connect/publish attempt failed with PLATFORM_DISABLED.' It also explains consequences of states (off, connect_off) and error conditions, leaving no doubt about the appropriate scenarios.

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

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

The annotations already establish that the tool is read-only and non-destructive. The description adds valuable behavioral context by disclosing pagination, the presence of platform statuses and metrics, and the precise sort order using publishedAt, scheduledAt, and createdAt.

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 compact and front-loaded, getting straight to the verb, resource, and filters in the first sentence. The second sentence adds ordering and usage guidance with 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?

For an 11-parameter read-only list tool with no output schema, the description adequately covers filtering, pagination, ordering, and result content. It omits a couple of filter dimensions like approvalStatus, but the schema covers those, so the description is sufficient 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 description coverage is 100%, so the baseline is 3. The description summarizes the filter categories and notes optionality, but it does not add meaning beyond what the input schema already documents for each 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?

The description uses a specific verb and resource ('List posts'), enumerates the filter dimensions, and clearly explains the output includes paginated results, platform statuses, and metrics. It also distinguishes itself from the visual dashboard, helping the agent separate it from sibling view_posts.

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

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

The description states an explicit use case: 'when the user wants to browse, filter, or check the status of existing posts as raw data'. It also adds an exclusion, 'not the visual dashboard', which implies a dashboard-oriented sibling tool without naming one explicitly.

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, and the description adds meaningful behavioral context: feeds are polled every 15 minutes and new items automatically become posts. It also discloses the returned fields, giving the agent a clear picture of what the tool does beyond its safety profile.

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 compact and front-loaded: the first sentence defines the tool's core function and behavior, and the second lists outputs and usage context. Every sentence contributes useful information without redundancy.

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

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

With no parameters, no output schema, and read-only annotations, the description fully covers what an agent needs to know: what the tool returns, how the feeds behave, and when to use it. 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?

The tool has zero parameters, so there is no schema burden for the description to carry. The description adds no parameter-level detail because none is needed; the baseline of 4 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 clearly states the tool lists RSS autopost feeds, defines what those are, and specifies the exact return fields. This unambiguously distinguishes it from sibling tools like create_rss_feed, update_rss_feed, and delete_rss_feed.

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

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

The description explicitly says 'Use this when the user wants their RSS autopost feeds,' giving clear context for when to invoke it. It does not enumerate alternatives or exclusions, but the no-parameter read-only nature makes such guidance less critical.

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 readOnlyHint=true, openWorldHint=false, and destructiveHint=false. The description adds useful behavioral context beyond annotations by enumerating the returned fields and noting that schedules also appear in the Repeat Posts page and Calendar. This helps an agent know exactly what to expect from the call.

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

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

Three short sentences, each earning its place: the action, the return payload, and the web-app/usage context. 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?

For a zero-parameter read-only list tool with no output schema, the description is complete: it states the scope, the returned fields, and the context in which to use it. Nothing necessary 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?

The tool has zero parameters, so there is no parameter documentation burden. The description still clarifies that the operation lists 'all' schedules, which is useful given the absence of filters.

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 ('List') and resource ('recurring post schedules'), and clearly differentiates this from schedule mutation tools like create_schedule, update_schedule, and delete_schedule. It also specifies the exact fields returned, leaving no ambiguity about the tool's purpose.

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

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

The description gives an explicit invocation context: 'Use this when the user wants their recurring posting schedules.' It also adds helpful context about the web app equivalents. It does not enumerate when-not-to-use cases or name alternative tools, but for a straightforward read-only list this is adequate.

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 annotations, it reveals that publishing is queued to all target channels, requires the post:publish role, and that approver-publishing a pending/rejected post implicitly approves it. These side effects and permission outcomes are behavior an agent couldn't infer from readOnlyHint=false/destructiveHint=false alone.

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

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

Four sentences, all high-signal: core action, queue behavior, auth/alternative, and when-to-use. The main effect is front-loaded; 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?

Covers the action, side effect, permissions, failure mode for contributors, and the edge case of pending/rejected posts. It omits details like invalid-state errors or return payload, but with a single parameter and no output schema these are not critical 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 fully documents postId with a clear description and 100% coverage, so baseline is 3. The description adds contextual color by saying the post is a draft or scheduled post, but adds no extra constraints or format 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 description opens with a concrete action — 'Publish a draft or scheduled post immediately' — and specifies the resource and timing. It further distinguishes itself by explaining the approval path (contributors must submit for approval) and that publishing as an approver implicitly approves, separating it from approve_post.

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

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

It explicitly states the intended trigger: 'Use this when the user wants to publish an existing draft or scheduled post right now.' It also gives when-not: contributors without post:publish get 403 and should use create/update with requestApproval instead.

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 communicate readOnlyHint=false and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds the story-specific platform context, but does not disclose further behavior such as whether the post is published immediately, status changes, or side effects. No contradiction with annotations.

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

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

The description is only two short sentences, front-loading the core purpose ('Publish a post as a story') before adding a usage hint. The second sentence is partly redundant with the first, but it does earn its place by explicitly stating when to use the tool.

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

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

Given the tool's low complexity, two fully documented parameters, and annotations covering the safety profile, the description provides enough context for an agent to invoke it correctly. It does not explain return values or prerequisites, but these are less critical for a simple publish action.

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

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

The input schema fully documents both parameters (postId and platform) with 100% coverage, including the enum for platform. The description's mention of 'Facebook or Instagram' merely restates the schema and adds no extra parameter-level meaning, 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 states a specific verb ('Publish') and resource ('a post as a story on Facebook or Instagram'), making the tool's function immediately clear. It also naturally distinguishes from sibling tools like publish_post by focusing on the story format and platforms.

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

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

The second sentence explicitly says 'Use this when the user wants to post an Instagram/Facebook story,' giving a clear trigger condition for selecting the tool. However, it does not mention alternatives or when not to use it, 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 only say readOnlyHint=false and destructiveHint=false, so the description carries the behavioral disclosure burden. It does so thoroughly: the post returns to draft with approvalStatus 'rejected', the author is notified and can resubmit, and specific error codes for 400/403/404 are given. No contradiction with annotations.

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

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

The first sentence states the core purpose and subsequent sentences cover permission, post-conditions, errors, and usage context. Slightly longer than strictly necessary due to enumerating error codes, but each sentence contributes meaningful information and the key facts are front-loaded.

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

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

For a mutation tool with no output schema, the description fully equips an agent: what happens to the post, who is affected, what permissions are needed, and all likely failure modes. No critical call-disambiguation information is missing relative to sibling tools.

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 postId and reason are already documented. The description adds context that the reason is shown to the author, but this is also in the schema's reason field. The description does not need to compensate for missing parameter info.

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 ('Reject a post awaiting team approval') and names the state the post must be in. The action is clearly distinguished from sibling approve_post and delete_post by focusing on the 'reject' workflow.

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 provides the trigger 'Use this when the user (an owner/admin/approver) wants to reject a post awaiting team approval' and includes the required role post:approve. It does not name the alternative approve_post or say when not to use it, but the intended 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?

The description is unusually transparent: it explains partial-failure retry behavior, the special 'unconfirmed' status trap, the exact 400 error code, the user-confirmation workflow, and the risk of duplicating posts with republish. Annotations only provide readOnlyHint and destructiveHint, so this behavioral context adds substantial value beyond structured fields.

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

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

The description is front-loaded with the core purpose, then methodically addresses scope, the unconfirmed edge case, the error code, and the practical user action. Every sentence carries operational weight; no filler or restatement of the schema is present.

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 tricky partial-failure and unconfirmed semantics are fully covered, as is the actionable error path. With no output schema, the only minor gap is that the success/response shape (e.g., per-platform results) is not characterized, but this is secondary for a retry operation.

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 already have solid descriptions. The tool description enriches the republish parameter by tying it to the UNCONFIRMED_REQUIRES_REPUBLISH error and the user-confirmation process, which tells the agent when the boolean must be set. This pushes it above 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?

Description opens with 'Retry publishing a failed or partially failed post' – a specific verb and resource that goes beyond the title. It clarifies scope by stating only failed platforms are retried, distinguishing it from publish_post and other sibling publishing tools without needing to name them.

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 closing sentence provides explicit when-to-use guidance: 'Use this when a post failed on some platforms and the user wants to retry just those.' It also gives a when-not via the 400 UNCONFIRMED_REQUIRES_REPUBLISH path, instructing the agent to ask the user to verify the platform before passing republish. It stops short of naming alternative sibling tools explicitly, so not 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 carry readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful context beyond these: that it searches a 'connected channel' (external platform data, reinforcing openWorldHint) and serves the drafting workflow. No contradictions with annotations.

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

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

The core function is front-loaded in the first sentence, which is ideal. The remaining two sentences provide workflow context, though 'Useful for finding users/pages to mention in posts' and 'Use this when you need @mention suggestions from a connected channel while drafting a post' are partially redundant and could be merged. Still, 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 simple tool (2 required parameters, no nested objects, no enums) with annotations covering the safety profile and a fully documented schema, the description is adequately complete. It clarifies the use case and scope. Minor omissions like result format and rate limits are acceptable given the tool's simplicity and read-only nature.

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 fully documented in the schema ('Search query for the mention lookup' and 'The channel ID to search mentions on'). The description echoes 'on a channel' but adds no format, syntax, or behavioral detail beyond what the schema provides, so 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 opens with a specific verb+resource+scope construction: 'Search for @mention suggestions on a channel.' This precisely identifies what the tool does and naturally distinguishes it from all siblings, none of which perform mention lookup. The '@mention' detail makes the resource unambiguous.

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

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

The description gives explicit when-to-use guidance: 'Use this when you need @mention suggestions from a connected channel while drafting a post.' This anchors the tool to a concrete workflow. It stops short of a 5 because it names no alternatives or explicit when-not-to-use conditions, though no competing sibling 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?

The description adds useful behavioral context beyond the annotations: partial-update semantics, the 'at least one field is required' constraint, and a specific 409 DUPLICATE_NAME error case. The idempotentHint is already annotated, and the description does not contradict it.

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

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

The description is two sentences long, with the core operation and partial-update requirement front-loaded. The error condition and usage guidance follow efficiently, and every sentence adds information without redundancy.

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

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

For a simple, three-parameter mutation tool, the description covers the essential invocation details: partial update, required-field condition, collision behavior, and intended usage. There is no output schema, and the description does not mention the return value or behavior for a nonexistent setId, which is a minor gap.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that at least one of name or channelIds must be supplied, even though the schema does not enforce this, and by reinforcing the replacement semantics of channelIds as 'change its channels.'

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

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

The description clearly states a specific action ('Update a channel set's name and/or channels') and identifies it as a partial update. This distinguishes it from sibling tools like create_channel_set, delete_channel_set, and list_channel_sets 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?

The description explicitly says when to use the tool: 'Use this when the user wants to rename a channel set or change its channels.' It provides clear context, though it does not explicitly mention alternatives or exclusion cases, which prevents 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 (mutation), idempotentHint=true, and destructiveHint=false. The description reinforces the mutation aspect and adds the specific behavioral scope: only 'name or color' are changed, implying other properties are untouched. This goes beyond the annotations by clarifying the limited effect of the update. No contradiction with annotations.

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

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

The description is two concise sentences. The primary action and scope are front-loaded, and the usage guidance is appended without redundancy. Every sentence earns its place; there is no filler or repetition of schema or annotation data.

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

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

For a simple tool with only three parameters, a fully described schema, and annotations covering safety and idempotency, the description provides sufficient context. It states the purpose and usage, and the schema covers parameters. With no output schema and no nested objects, nothing else is needed for an agent to call this tool correctly.

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

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

The input schema has 100% description coverage for all three parameters (labelId, name, color). The description adds no extra meaning beyond what the schema already provides—it merely restates that name and color can be updated. Since the schema handles the parameter documentation, the description's contribution is minimal, so a 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 clearly states the verb ('update') and the resource ('existing label'), and explicitly specifies the scope ('name or color'). It distinguishes itself from sibling tools like create_label and delete_label by requiring an existing label, and the specific fields are named, leaving no ambiguity about what the tool does.

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

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

The description provides a direct usage condition: 'Use this when the user wants to rename or recolor a label.' This tells the agent when to select this tool. It does not explicitly mention when not to use it or name alternatives, but the condition is clear enough to avoid confusion with create_label or delete_label. A small gap is the absence of exclusions (e.g., if the label doesn't exist), but that is implied by 'existing'.

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 readOnly=false, idempotentHint=true, and destructive=false, so the bar is for added context. The description discloses the reset-to-draft behavior for failed/partial posts and the status transition rules, which adds value beyond the annotations. It does not contradict them.

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

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

Three sentences with no filler: the lead sentence states the core action, the second gives editability constraints and reset semantics, and the third clarifies status transitions and routes to publish_post. The most decision-relevant facts are front-loaded.

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

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

Despite the large platformSpecific nested schema, the description is sufficiently complete for selecting and invoking the tool because the input schema fully documents all parameters. It supplies the missing operational context: which post states are editable, reset-on-edit behavior, and the publish_post alternative. No output schema exists, but for an updating tool this is acceptable.

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%, placing the baseline at 3. The description adds a nice coarse summary of updatable fields and references the status enum behavior, but it does not add parameter syntax or format details beyond what the comprehensive input schema already provides.

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

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

States a specific verb+resource ('Update an existing post') and enumerates the mutable aspects: content, schedule, media, labels, status, and platform-specific settings. The second half clearly distinguishes it from publish_post and implies the create_post counterpart.

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

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

Gives an explicit when-to-use statement ('Use this when the user wants to edit an existing post.') and a when-not condition ('use publish_post to publish immediately'). It also constrains usage to draft, scheduled, failed, or partial posts, naming an alternative tool where relevant.

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

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

The description discloses a non-obvious side effect: changing feedUrl re-baselines the feed, resets check state, and posts only items published after the change, 'so the new feed's backlog is not flooded.' This goes beyond the annotations (idempotentHint=true, destructiveHint=false) and adds behavioral context that matters for correct invocation and expectation setting.

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

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

The description is two concise sentences with no filler. The core purpose and the most important caveat (re-baselining) are front-loaded, and the usage trigger follows naturally. Every sentence earns its place.

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

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

Given the tool's 8 parameters but 100% schema coverage, the description plus schema is complete for correct invocation. The description covers the key behavioral nuance and usage context; only a return-value note is absent, but no output schema exists and this is a mutation tool, so that absence is not a critical 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 the input schema already documents all eight parameters thoroughly. The description adds the general notion of partial update and the feedUrl re-baseline behavior, but that re-baseline is also stated in the schema feedUrl property description. The description does not need to compensate for parameter documentation gaps.

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

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

The description uses a specific verb and resource ('Update an RSS autopost feed (partial update)') and clearly distinguishes mutation from the create/delete/list RSS feed siblings. The parenthetical 'partial update' adds precision about the operation's scope.

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

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

The description explicitly states when to use it: 'Use this when the user wants to change, pause, or re-point an RSS autopost feed.' It does not explicitly name alternatives or when-not-to-use, but the categories of change are concrete and sufficient for an agent to route correctly relative to create/delete/list siblings.

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

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

The description adds a meaningful behavioral detail beyond annotations: 'The next run time is recomputed by the server when timing changes.' This supplements the idempotentHint and destructiveHint annotations. However, it does not clarify whether updates are partial or full replacement, or how parameter interactions (e.g., dayOfWeek with frequency) are handled.

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, with the core action and field scope front-loaded. The final sentence is somewhat redundant with the title, but the description remains tight and scannable.

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 11-parameter update tool with no output schema, the description gives enough initial orientation but omits important operational context such as whether omitted fields are preserved, how frequency-dependent fields interact, and what the response will contain. The schema fills parameter detail, but the overall update semantics are underspecified.

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 each parameter already has a clear description. The prose description mostly restates parameter categories without adding new semantic details, so it does not elevate beyond the baseline for well-covered schemas.

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

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

The description states a specific action ('Update an existing recurring schedule') and enumerates the main changeable aspects: name, content template, frequency/timing, timezone, media, and active status. This clearly distinguishes update_schedule from sibling create_schedule, delete_schedule, and list_schedules tools.

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

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

It explicitly says 'Use this when the user wants to change a recurring schedule,' which provides clear contextual guidance for the main use case. It does not mention exclusions or when a sibling tool like create_schedule would be more appropriate, but the 'existing' phrasing and update intent are reasonably 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 only indicate non-read-only and non-destructive, so the description carries the behavioral burden. It adds meaningful behavior: the file is stored in BulkPublish, supported formats are listed, max size is stated, and the url/filePath exclusivity is disclosed. It does not mention return values or side effects beyond storage, but no contradiction exists.

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

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

Four sentences cover purpose, source, storage, formats, size, and parameter exclusion with no redundant wording. The most important usage guidance is front-loaded.

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

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

The description covers input selection, constraints, storage destination, and intended use case. Since there is no output schema, it would benefit from explicitly stating what is returned (e.g., a media ID), but the current information is sufficient for most correct invocations.

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

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

Schema description coverage is 100%, so parameters are already documented. The description adds value by clarifying that url and filePath are mutually exclusive and by providing supported format and size constraints that affect parameter usage.

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 ('upload') and resource ('media file'), and clearly scopes it to images/videos from a URL or local file path. It also states the storage destination (BulkPublish), which distinguishes it from read/list/delete media 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?

The description explicitly says to use this when the user provides an image/video to attach to a post, which gives clear invocation context. It does not explicitly name alternatives or exclusion conditions relative to sibling upload tools like create_media_upload, 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 establish readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by indicating the tool opens an interactive visual dashboard rather than simply returning raw data, which is a meaningful behavioral trait beyond the schema.

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

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

Two sentences with no filler. The first sentence front-loads the tool's purpose and contents, and the second immediately gives usage guidance and the sibling alternative. Every word 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 read-only tool with zero required parameters, a 100% documented schema, and an output schema, the description covers purpose, contents, and usage context. Nothing essential is missing for an agent to decide whether to call it and how.

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

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

Schema description coverage is 100%, with both from and to parameters clearly documented including defaults and format examples. The description mentions 'date range' but adds no parameter-level detail beyond what the schema already provides, so the 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 uses a specific verb ('Open') and a clear resource ('interactive analytics dashboard'), then enumerates exactly what the dashboard contains: totals, status breakdown, per-platform stats, and daily post counts. It also distinguishes itself from the key sibling get_analytics by emphasizing the visual/interactive nature.

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

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

The description explicitly says to use this tool when the user wants an interactive analytics dashboard and tells the agent to prefer it over get_analytics for a visual view. It names the relevant alternative, though it does not clearly state the condition under which get_analytics should be chosen instead.

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 signal read-only, non-destructive behavior. The description adds value beyond annotations by clarifying that this opens an interactive view rather than returning a plain list, and by indicating the status-related fields shown. No contradiction with annotations is present.

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

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

Two concise sentences with no filler. The core purpose is front-loaded, and the usage guidance follows immediately, each sentence earning 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 no-argument, read-only view tool with an output schema, the description covers what the view shows and when to use it. Annotations cover the safety profile, making the definition complete for the agent.

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

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

The tool has zero parameters, so parameter-level documentation is unnecessary. The baseline of 4 applies because there is nothing the description needs to explain about parameters.

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

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

The description names a specific verb ('Open') and a clear resource ('connected social channels') with the detail of platform, account, and connection/token status. It distinguishes itself from siblings like list_channels through the 'interactive view' framing, though it does not explicitly name a sibling alternative.

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

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

It explicitly states when to use the tool: 'Use this when the user wants an interactive view of their connected channels.' It does not mention when not to use it or name alternatives, but the stated trigger 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.

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

Annotations already cover the read-only/non-destructive safety profile, so the description only adds the interactive gallery and thumbnails context. It does not disclose pagination behavior, default limit handling, or whether 'interactive' means a rendered UI vs. returned data, but output schema and annotations lessen the burden.

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, focused sentences. The main action and visual browsing purpose are front-loaded, with 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 single-parameter, read-only, output-schema-backed tool, the description is nearly complete. The only meaningful gap is the lack of explicit differentiation from list_media, but the phrase 'browse visually' largely covers that.

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

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

The only parameter, limit, is fully documented in the schema with a default value. The description adds no additional semantics beyond what the schema already 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 action ('Open an interactive gallery') and identifies the resource ('uploaded media files') with a clear presentation format ('thumbnails and metadata'). It also signals the visual browsing use case, which distinguishes it from programmatic list tools like 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?

It explicitly gives the trigger condition: 'Use this when the user wants to browse their media library visually.' However, it does not name alternatives or provide when-not-to-use guidance, especially given the presence of list_media and get_media as sibling tools.

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 the safety profile is covered. The description adds meaningful behavioral context by labeling this an 'interactive list' / 'dashboard', which signals a UI-style presentation rather than a plain data response, and lists the post fields shown.

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

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

Two sentences with no redundant wording. The core purpose is front-loaded, and the usage guidance with the sibling comparison appears right after, making the description compact and easy to parse.

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, two-parameter tool with a complete input schema, an output schema, and annotations covering mutation safety, the description fully covers what an agent needs to decide when to invoke it and how it behaves. No critical gaps remain.

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 the 'limit' and 'status' parameters are already well-described in the input schema. The description only restates that status filtering is optional, adding no new semantic 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?

States a specific verb ('Open') and resource ('posts'), and specifies the content (status, schedule, channels). It explicitly distinguishes itself from sibling 'list_posts' by positioning itself as the visual/interactive view, making the tool's purpose immediately clear.

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

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

Explicitly states when to use the tool ('when the user wants to see their posts as an interactive dashboard') and names the alternative ('prefer over list_posts for a visual view'). This gives an agent a clear decision rule between view_posts and list_posts.

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 mark the tool as read-only and non-destructive; the description adds useful behavior beyond that by indicating it provides an interactive visual view and enumerates what usage dimensions are shown. It does not contradict any annotation, and the additional detail is relevant for setting agent expectations.

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

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

Two concise sentences: the first states what the tool does and what it shows, and the second gives the usage trigger. There is no filler or repetition, and the most important information is front-loaded.

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

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

With no parameters, a read-only annotation, and an output schema present, the description provides everything needed for an agent to select and invoke this simple tool. It clearly defines scope, content, and the visual nature of 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?

The tool has zero parameters, so the description has no parameter burden to carry. Per the baseline for no-parameter tools, no additional parameter meaning is required.

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 ('Open') and resource ('current account usage'), and lists concrete contents: daily/monthly post counts, channel counts, and media storage. It also signals a visual/interactive presentation, which distinguishes it from the nearby get_quota_usage sibling.

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

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

The description explicitly says to use it 'when the user wants a visual view of their plan usage,' giving clear context. It does not name alternatives or exclusion cases, such as when raw quota data might be preferred over a visual view, so it falls just short of full guidance.

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