BulkPublish

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

Annotations already mark destructiveHint=true, but the description adds valuable context by stating the upload's stored parts are permanently freed and that 'This action cannot be undone.' This goes beyond the simple destructive flag and clarifies the irreversible side effect.

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 and clear, but the final sentence ('Use this when a chunked upload should be cancelled and its stored parts freed.') largely repeats the first two sentences. The redundancy does not add new information, so it could be trimmed.

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

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

For a destructive, low-complexity tool, the description covers the critical aspects: what it does, when to use it, when not to use it, and irreversibility. The schema fully documents the two required parameters, and there is no output schema demanding explanation. It is sufficiently complete for an agent to invoke 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?

Both parameters have full descriptions in the schema, and the description itself does not add additional meaning beyond what the schema already provides. Since schema coverage is 100%, the baseline of 3 is appropriate.

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

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

The description states a specific action ('Abort an in-progress chunked upload') and the resource it affects, and explains the key consequence ('permanently free its stored parts'). This clearly distinguishes it from completion-oriented sibling tools like 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 when to use it ('Use only when the upload should be cancelled') and when not to use it ('do not use this after all parts have been uploaded if you intend to complete the upload'). This gives the agent a clear decision rule.

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

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

The description adds rich behavioral context beyond the annotations: it discloses the permission requirement, the scheduling effect (publishes at scheduled time or immediately if past), the in-app notification to the author, and specific error codes (400, 403, 404). This fully informs the agent of consequences 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 concise and well-structured, delivering purpose, permissions, behavior, errors, and usage guidance in four tight sentences. No filler or redundancy; each clause contributes actionable information.

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

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

For a single-parameter mutation tool with no output schema, the description covers all necessary context: when to use it, prerequisites, side effects, error conditions, and target state. Nothing essential is missing for an agent to invoke it correctly.

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

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

The input schema already documents postId 100% with 'The post ID to approve.' The description does not add additional meaning about the parameter beyond what's in the schema, 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 ('Approve') and resource ('a post awaiting team approval'), and further clarifies the exact condition ('approvalStatus pending'). It implicitly distinguishes itself from siblings like reject_post and publish_post by focusing on the approval workflow step.

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 includes an explicit usage directive: 'Use this when the user (an owner/admin/approver) wants to approve a post awaiting team approval.' It also specifies the required role. It does not explicitly name reject_post as the alternative for the opposite action, but the when-condition 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 signal this is destructive (destructiveHint: true) and not read-only. The description adds natural-language clarity about the bulk nature of the operation, but does not disclose additional behavioral details such as partial failure handling, irreversibility beyond the annotation, or side effects. This is adequate but not rich.

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 focused sentences: the first states what the tool does, the second states when to use it. There is no filler, repetition, or irrelevant context, and the core action 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 moderate-complexity bulk action tool, the description plus a fully described input schema and annotations cover the essential selection and invocation needs. No output schema exists, but the return format is not critical for choosing or calling this tool correctly; the conditional reschedule parameter is documented in the 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%, so the baseline is 3. The description does not add parameter-level detail, but the schema already documents the action enum, postIds array, and the conditional requirement for scheduledAt when action is 'reschedule'.

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 ('perform a bulk action'), a clear resource ('multiple posts'), and explicitly enumerates the supported operations: deleting, retrying, and rescheduling. The phrase 'multiple posts' distinguishes it from singular sibling tools like delete_post and retry_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?

The description gives a clear when-to-use signal: 'Use this when the user wants to delete, retry, or reschedule many posts in a single request.' It does not explicitly name alternatives or exclusions, but the bulk-versus-single distinction provides clear context.

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

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

Beyond the basic mutation implied by the annotations, the description discloses meaningful behaviors: the server assembles parts, verifies existence/size/magic bytes/storage quota, records the media file, mirrors finalize_media_upload's response shape, and automatically aborts on failed assembly. This is substantial context the annotations do not provide.

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 efficient sentences deliver the core behavior, verification steps, failure handling, response-shape reference, and usage condition. It is front-loaded with the primary action and contains no filler.

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

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

For a 9-parameter mutation tool with no output schema, the description provides solid context: verification behavior, automatic abort, and a pointer to finalize_media_upload for response shape. It is slightly dependent on the agent knowing what finalize_media_upload returns, but otherwise the call context is adequately covered.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description adds only a small touch by mentioning that parts must be collected with their ETags, but otherwise it does not deepen understanding of the individual parameters beyond what the schema states.

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

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

The description clearly states the tool's verb and resource: it completes a chunked upload by assembling parts, verifying the stored object, and recording the media file. It references finalize_media_upload to position its behavior, though it does not explicitly state how it differs from that sibling beyond being the chunked variant.

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

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

The description gives an explicit usage condition: 'Use this when all parts of a chunked upload are PUT and their ETags collected.' This is clear context for when to invoke the tool, though it does not explicitly mention when not to use it or name a specific alternative to prefer 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?

Beyond the annotations (readOnlyHint false, destructiveHint false), the description explains the important interaction model: the tool opens a UI, the user finishes there, and only on submit does it create the post via create_post. It also discloses pre-fill behavior and connected-channel display. Minor omission: no statement about cancellation or how scheduling is completed, but the output schema covers return 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 sentences, front-loaded with the action and immediate behavioral context, and the routing guidance is delivered in a single clause. No filler or repetition of 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 an interactive compose tool, the description covers what the tool does, how the user flow completes, what happens on submit, and when to prefer it over create_post. Combined with a full schema and an output schema, nothing essential is missing for an agent to invoke or route to 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 input schema already fully documents content as 'Optional initial text to pre-fill the composer with' (100% coverage). The description's 'pre-fills any provided text' restates that without adding syntax, defaults, or constraints, so the description adds no significant meaning 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?

The description names a specific action (open an interactive composer), the resource (a social media post), and the scope (draft or schedule, choose from connected channels, pre-fill text). It explicitly differentiates from the sibling create_post by framing this as the interactive, review-first path, so an agent can distinguish them without opening schemas.

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

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

Ends with explicit routing guidance: 'Use this when the user wants to compose a post interactively in a UI — prefer this over create_post when they'd review before posting.' This names the alternative tool and the condition that selects compose_post over it.

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

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

Beyond the annotations, the description adds meaningful behavioral detail: duplicate names fail with a 409 DUPLICATE_NAME error and organizations are limited to 50 sets. This warns the agent about realistic failure modes and constraints without contradicting the write-oriented readOnlyHint=false annotation.

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 cover definition, constraints, and usage trigger with no filler. The most important information is front-loaded, and 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 create operation with two required parameters and no output schema, the description covers purpose, constraints, and failure behavior sufficiently. It does not describe the return value, but this is mitigated by the schema coverage and the tool's straightforward 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 coverage is 100%, so both parameters are already documented. The description adds extra context for 'name' by noting uniqueness per organization, and frames 'channelIds' as the group of channels being saved for one-click targeting, which reinforces the intent behind the parameter values.

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 and object: 'Create a channel set,' and immediately defines what a channel set is ('a saved channel grouping for one-click multi-channel targeting'). This makes the tool's role obvious and distinguishes it from sibling tools like list_channel_sets, update_channel_set, and delete_channel_set without needing to open the schema.

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

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

The description includes an explicit 'Use this when the user wants to save a group of channels for one-click targeting,' which gives a clear trigger condition. It does not explicitly contrast it with update_channel_set or list_channel_sets, but the creation intent 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 annotations already signal that this is a write operation (readOnlyHint=false) and not destructive. The description adds only that labels organize posts/media, which is more about purpose than behavior. It does not disclose side effects, defaults, or permissions, but no contradiction exists between description and 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 short sentences with no filler. The first sentence communicates the core action and scope, and the second gives direct usage 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 simple creation tool with three schema-covered parameters and no nested objects, the description plus schema provides enough information for an agent to invoke it correctly. The lack of output schema information is a minor gap given the low complexity.

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

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

Schema description coverage is 100%, so the parameters name, type, and color are already fully documented in the schema. The description mentions 'posts or media files,' loosely aligning with the type enum, but it does not add meaningful detail beyond the schema. Baseline 3 applies.

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

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

The description states a clear verb and resource ('Create a new label') and adds the domain context of organizing posts or media files. It does not explicitly distinguish itself from the sibling label tools like list_labels, update_label, or delete_label, but the word 'new' combined with 'Create' makes the creation intent 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?

It explicitly says 'Use this when the user wants a new label/tag,' giving direct guidance for when this tool is appropriate. It does not mention alternatives (e.g., update_label for existing labels) or exclude cases where it should not be used, so it stops short of full differentiation.

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

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

Annotations already cover read-only and destructive hints, and the description adds useful context about browser vs scripted use and large direct uploads. However, it does not disclose potential follow-up steps such as finalization or expiration of the reserved URL, which would be valuable for a multi-step upload flow.

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 concise and front-loaded with the core behavior, then provides usage guidance. The second sentence is slightly repetitive after the first, but it still contributes useful alternative selection information.

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

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

For a simple two-parameter tool with no output schema, the description is fairly complete: it explains the purpose, audience, and when to prefer the alternative. The main gap is not mentioning that this is the first step in a larger media-upload workflow that may require a later finalize call.

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 descriptions cover both parameters completely (contentType as MIME type, sizeBytes as file size), so the description does not need to add much. The description adds context about the presigned URL use case but no new parameter-level meaning 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?

The description states a specific verb and resource: 'Reserve a presigned R2 upload URL for a direct browser upload.' It also explicitly calls out the composer UI context and differentiates itself from upload_media, making its distinct role clear among many media-related sibling 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?

The description gives explicit usage guidance: 'For scripted uploads use upload_media instead' and 'Use this when you need a presigned URL for a large direct upload (advanced; prefer upload_media for normal files).' This clearly tells an agent when to choose this tool over its primary 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?

With no meaningful behavioral annotation coverage beyond readOnlyHint/destructiveHint flags, the description carries the full burden and succeeds. It discloses the fixed 10MB partSize, presigned URL validity of 3600s, the requirement to PUT each slice and collect ETags, and that the upload completes via a separate call. No annotation 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?

The description is compact and front-loaded: purpose first, then return values, then step-by-step workflow, then when-not-to-use guidance. Every sentence adds operational information with 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?

There is no output schema, so the description correctly explains what the tool returns and how to use those values. It also covers size limits, chunking mechanics, URL expiration, ETag handling, and the completion step. For a tool of this complexity, 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%, so the schema already documents contentType and sizeBytes, including allowed sizes. The description adds the 10MB chunking context and clarifies how sizeBytes relates to the multipart flow, but this is contextual rather than necessary to understand the two parameters. 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 states a specific verb ('Start') and resource ('chunked direct-to-storage upload'), and clearly distinguishes it from ordinary single uploads. It also frames the output (r2Key, uploadId, partSize, presigned URLs) and explicitly names the sibling complete_multipart_upload as the next step, making the tool's role unmistakable.

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

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

Usage guidance is explicit: 'For ordinary files prefer upload_media' and 'Use this when a file is too large for a single upload'. It gives concrete size thresholds, the chunking workflow, and points to complete_multipart_upload as the required follow-up, leaving no ambiguity about when to choose this tool.

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

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

Annotations only carry readOnlyHint=false and destructiveHint=false, so the description carries most of the behavioral burden. It goes well beyond the baseline by explaining draft/schedule behavior, platform-specific content overrides, and critical constraints: YouTube and TikTok require video, and Instagram defaults to feed_photo. These are non-obvious traits an agent must know before calling the tool.

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

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

The description is compact yet information-dense, with the core action first, then capabilities, then two 'IMPORTANT' caveats, and a final use-case sentence. Every sentence earns its place, and the critical constraints are highlighted rather than buried.

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

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

Given the tool's complexity (14 parameters, nested objects, no output schema), the description provides the essential selection criteria and the most dangerous platform defaults. It does not enumerate every platform-specific quirk, but those are already richly documented in the input schema, so the description is highly adequate without being exhaustive.

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 meaningful parameter-level guidance beyond the schema, particularly 'Instagram defaults to feed_photo — set postTypeOverrides for video content (reel, feed_video)' and the mapping of capabilities to labels, media attachments, and thread format. This elevates it above the baseline but it still doesn't detail every parameter, which the schema already handles.

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 pair ('Create a new social media post') and immediately narrows the scope to drafting or scheduling a single new post. The closing sentence ('do not publish immediately unless asked') differentiates it from publish_post, making the tool's purpose unambiguous even among many 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 states when to use the tool: 'Use this when the user wants to draft or schedule one new post.' It also warns against immediate publishing. However, it never names alternatives like publish_post, compose_post, or bulk_posts, so the when-not guidance relies on inference rather than explicit sibling 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses meaningful behavioral traits: 15-minute polling cadence, automatic post creation, server-side validation that feedUrl is a reachable public RSS 2.0 or Atom feed, and the organization limit of 20 feeds. These details give the agent actionable expectations about side effects and constraints.

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

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

The description is four short, information-dense sentences. The core purpose is front-loaded, followed by behavioral detail, a constraint, and a usage trigger, with no redundant or filler content.

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

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

For a complex create tool with a nested fieldMapping schema and no output schema, the description supplies essential operational context: polling interval, reachability validation, org-level feed limit, and automatic posting behavior. It does not mention return values or failure semantics, but the rich input schema already covers parameter-level 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 all six parameters, including mode, fieldMapping, and requireApproval, are already documented at the property level. The free-text description adds little parameter-specific guidance beyond restating feedUrl validation, 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 opens with a specific verb and resource, 'Add an RSS autopost feed,' and explains the mechanism: the feed is polled every 15 minutes and new items become posts on chosen channels. This clearly distinguishes it from sibling tools like update_rss_feed, delete_rss_feed, and list_rss_feeds.

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

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

The description includes an explicit usage trigger: 'Use this when the user wants new items from an RSS/Atom feed to become posts automatically.' It does not enumerate when not to use the tool or explicitly route to update_rss_feed for existing feeds, but the create-only semantics and sibling context make the appropriate use clear.

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

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

Annotations only say the call is non-read-only and non-destructive; the description adds the meaningful side effects that posts are automatically created and published, that the schedule appears in Repeat Posts/Calendar, and that post records are generated lazily only when an occurrence fires. This goes beyond the structured fields, though it slightly oversimplifies the requireApproval case.

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 the core action and main side effect first, followed by useful visibility/record-timing context and a final usage directive. 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?

Full schema coverage plus disclosures about automatic publishing, schedule visibility, and post-record timing cover the main operational expectations. The only notable omission is a caveat about requireApproval delaying publication, but the schema describes that parameter in detail, so this is largely complete.

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

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

Schema description coverage is 100% and every parameter already carries a type/default/conditional requirement, so the description need not repeat them. It adds no new parameter-level semantics, making the baseline 3 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 action ('Create') and resource ('recurring post schedule'), and clarifies the semantic difference from immediate posting by explaining posts are generated on a frequency and a post record only exists after an occurrence fires. This clearly distinguishes it from sibling create_post and schedule management 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?

Explicitly says 'Use this when the user wants a recurring posting schedule,' giving a clear triggering condition. It does not name alternatives such as create_post for one-off posts, but the recurring context makes the intended use 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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds value by specifying what is destroyed (the channel set) and what is preserved (the channels themselves), giving the agent a clearer safety picture beyond the raw 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 sentences with no filler. The primary action is front-loaded, the non-destructive scope is stated immediately, and the usage directive is concise. 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 single-parameter delete operation with strong annotations, the description is fully sufficient. It explains what the tool deletes, what it leaves untouched, and when to invoke it. No critical information is missing for an agent to call it correctly.

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

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

The schema description covers 100% of the single parameter, setId, with 'The channel set ID to delete.' The description's mention of 'by ID' aligns with the schema but adds no additional format, type, or usage nuance. Baseline 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 states a specific verb ('Delete'), a resource ('channel set'), and the key scoping detail ('by ID'). It also disambiguates from sibling tools by noting that deleting the set does not affect the channels themselves, which clearly differentiates it from channel-level operations.

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 an explicit trigger: 'Use this when the user wants to remove a saved channel set.' It gives clear when-to-use context, though it does not explicitly name alternatives or state when not to use it. This is clear context without exclusions.

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 meaningful behavioral context beyond the annotations by disclosing that deletion also removes the label from all associated posts or media. This is important side-effect information for an agent calling the tool.

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

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

The description is two compact sentences, front-loads the core action, and includes the key side effect without unnecessary elaboration. 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 single-parameter delete operation, the description plus annotations provide sufficient context: destructive intent is flagged, idempotency is noted, and the label removal side effect is explained. It does not describe return values, but this is less critical for a delete action with no output 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?

The schema already fully documents the single labelId parameter with 100% coverage. The description's 'by ID' phrasing only restates the schema and adds no substantial new semantic information.

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 the exact operation ('Delete a label by ID') and the resource acted upon, then clarifies the scope by saying it removes the label from associated posts or media. This makes it clearly distinct from siblings like create_label, update_label, and list_labels.

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 'Use this when the user wants to delete a label,' giving a clear trigger condition. It does not mention alternative tools for create/update scenarios, but the intent 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 mark destructiveHint, so the bar is lower. The description adds useful behavioral detail by specifying that it removes the file from storage and detaches it from any posts, going beyond the annotation flags.

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 each sentence contributing: the operation, the concrete effect, and the usage context. There is minor redundancy in repeating 'delete a media file,' but no wasted content.

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

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

For a single-parameter delete operation, the description plus annotations fully cover what an agent needs: what it does, what it affects, when to use it, and that it is destructive. An output schema is not necessary for this 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 mediaId is fully documented in the schema. The description adds no additional parameter 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?

States a specific verb and resource ('Delete a media file by ID') plus concrete effects ('Removes... detaches...'). This clearly distinguishes it from sibling delete tools for posts, labels, schedules, and other resources.

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

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

Explicitly says 'Use this when the user wants to delete a media file.' This gives clear usage context, though it does not name exclusions or alternatives, which is acceptable given the resource is distinct.

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 convey destructiveHint=true, idempotentHint=true, and readOnlyHint=false. The description adds valuable context beyond these annotations by specifying the post states eligible for deletion. It also reinforces permanence with 'permanently remove,' which aligns with destructive 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?

The description is two short sentences with no filler. The action and primary constraint are front-loaded ('Delete a post by ID'), followed by the eligibility condition and usage intent. Every sentence contributes value.

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 delete operation with one parameter and no output schema, the description covers the essential aspects: what it does, when it can be used, and the permanent nature. With annotations and full schema coverage, no critical information 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 provides full coverage (100%) for the single parameter 'postId' with its description. The tool description does not add new meaning about the parameter (e.g., format, constraints) beyond the schema, so it meets the baseline for high 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 identifies the action ('Delete'), the resource ('a post'), and the qualifier ('by ID'). It also specifies the scope ('Only draft and failed posts') which distinguishes it from other post-related tools like publish_post or update_post.

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

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

The description provides clear usage context ('Only draft and failed posts can be deleted') and states the goal ('when the user wants to permanently remove a post'). It implies that posts in other states should not be deleted here, but it does not explicitly name alternatives like retry_post or update_post.

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

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

Beyond the annotations (destructiveHint=true, idempotentHint=true), the description discloses two important side effects: it stops polling and preserves already-created posts. This clarifies what is destroyed and what survives, which is exactly the kind of context that helps an agent set expectations. 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 description is three short sentences, each with a distinct job: state the operation, state the side effect, state the intended use. There is no redundant or promotional language, and the key verb and object 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 single-parameter delete operation, the description covers the action, the side effect on related posts, and when to use it. The annotations already provide destructive and idempotent hints, and the schema fully documents feedId. Nothing critical is missing for an agent to call 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?

The only parameter, feedId, is already fully documented in the schema with 'The RSS feed ID to delete,' so the description does not need to add more. The phrase 'by ID' in the description simply mirrors the schema without adding new format or constraint details. At 100% schema coverage, the baseline of 3 is appropriate.

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

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

The description states a specific action ('Delete'), a precise resource ('RSS autopost feed'), and the input method ('by ID'). It also adds scope by noting that polling stops and already-created posts are kept, which distinguishes it from deleting posts, media, or schedules. This is more specific than the title and differentiates it from sibling tools like update_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 includes an explicit usage condition: 'Use this when the user wants to stop and remove an RSS autopost feed.' This tells an agent when to invoke it with confidence. It does not name alternative tools for related scenarios (e.g., pausing without deletion), so the guidance is clear but not exhaustive.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is known. The description adds the specific consequence 'Stops all future posts from this schedule,' which provides context beyond the annotations. It does not mention reversibility or permissions, but the annotations cover the key safety aspects.

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 concise and front-loaded with the action. However, the third sentence ('Use this when the user wants to stop and delete a recurring schedule.') is partially redundant because the first two sentences already convey the deletion and its effect. Slightly tighter phrasing would earn a 5.

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

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

For a simple one-parameter delete operation, the description is complete. It states the purpose, the effect, and when to use it. The annotations cover read-only and destructive hints, and no output schema is needed. There is nothing essential missing 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 covers 100% of parameter documentation—'scheduleId' is described as 'The schedule ID to delete.' The description adds nothing new about the parameter beyond saying 'by ID,' which is already implied. With high schema coverage, 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 the action: 'Delete a recurring schedule by ID' and distinguishes it from update_schedule and create_schedule by specifying the deletion aspect. It also clarifies the effect ('Stops all future posts'), leaving no ambiguity about what the tool accomplishes.

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 to stop and delete a recurring schedule.' It does not explicitly mention alternatives or when not to use it, but the condition is clear enough for an agent to route correctly. It could be improved by contrasting with update_schedule for pausing vs. deleting.

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 as a write operation (readOnlyHint=false, destructiveHint=false). The description adds useful workflow nuance: it is the final registration step after a browser PUT, used by the composer UI, and is marked advanced. It does not go into idempotency or validation, but the annotations reduce that 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 sentences with no filler: the first states the operation and pairing, the second gives the precise invocation condition. Everything 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?

The description is complete enough for an agent to know when and why to call this tool, especially with the fully described schema and sibling names available. It could mention result or post-condition behavior, but the absence is not a serious gap for this workflow.

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

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

Schema description coverage is 100%, so all parameters are already explained in the schema. The description adds no parameter-specific meaning beyond the workflow context, 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 uses a specific verb and resource ('Record an uploaded R2 object as a media file') and anchors it to a concrete workflow: the browser PUT paired with create_media_upload. This clearly distinguishes it from related siblings like create_media_upload, upload_media, 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?

It gives an explicit trigger condition ('Use this when a presigned direct upload finished') and identifies its pairing with create_media_upload. It does not explicitly rule out alternatives like upload_media or complete_multipart_upload, but the direct-upload context is strong enough to guide 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 cover the read-only and non-destructive nature of the tool. The description adds behavioral context by detailing the shape of the returned summary: total posts, status breakdown, per-platform stats, and daily counts. It could go further by noting aggregation semantics or timezone handling, but the added output detail is meaningful.

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 with no filler. It front-loads the core action and resource, then gives concrete return details, then closes with 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?

For a read-only summary tool with two well-documented parameters and no output schema, the description adequately covers the callable behavior, return contents, and usage context. It does not mention sibling view_analytics or potential aggregation limitations, but the missing details are minor given the tool's simplicity.

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 (from and to) are fully documented with ISO format examples in the schema itself. The description only mentions 'date range' at a high level and adds no additional semantic information beyond what the schema already provides, 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 action and resource: 'Get an analytics summary for a date range,' and it lists concrete output categories like status breakdown and per-platform stats. It clearly differentiates itself from per-post tools like get_post_metrics, but it does not explicitly distinguish itself from the similarly named sibling view_analytics, so it stops short of full sibling differentiation.

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

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

The description provides an explicit use condition: 'Use this when the user asks how their content performed overall, across channels and over a date range.' This gives clear context for when to invoke the tool, though it does not name alternative tools or state when not to use it, 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 mark it read-only and non-destructive. The description adds transparency about what the call returns (token validity, connection status, issues) and the object it applies to (a connected channel). No contradiction.

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 compact sentences, front-loaded with the core action and followed by return value and 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 one-parameter read-only health check, the description covers the trigger, the checked object, and the returned fields. No output schema exists, but the high-level return description is sufficient for an agent to call it correctly.

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

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

The schema already documents the single required parameter with 100% coverage. The description only restates that it applies to a connected channel, adding no extra syntax or format guidance beyond the schema.

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

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

States a precise verb ('Check') and resource ('health status of a connected channel'), then lists the exact dimensions returned (token validity, connection status, issues). This distinguishes it from sibling tools like get_channel_options, list_channels, and get_quota_usage.

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

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

Explicitly says 'Use this when the user asks whether a channel's connection/token is healthy,' giving the agent a clear trigger. It does not name alternatives or exclusions, but the context 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 establish readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context by specifying that the result is platform-specific and includes options like post types, character limits, and media requirements, which helps the agent know what kind of information to expect without claiming any 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?

The description is two tightly written sentences. The first states the core function and examples; the second gives the practical use case. There is no redundant or filler content.

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

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

This is a simple read-only tool with one fully documented parameter. The description explains what the tool returns at a category level (post types, character limits, media requirements) and when to call it. Although there is no output schema, the examples provide enough context for an agent to invoke the tool and interpret the response.

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

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

The only parameter, channelId, is already fully described in the input schema as 'The channel ID to get options for.' Since schema description coverage is 100%, the description does not need to add parameter-level detail. The baseline of 3 is appropriate because the description adds no further 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 starts with a specific verb and resource: 'Get platform-specific options for a channel,' and then clarifies with concrete examples (post types, character limits, media requirements). This clearly distinguishes it from sibling read tools like get_channel_health or get_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?

The description explicitly states when to use the tool: 'Use this when you need a platform's valid post types before creating a post for it.' This gives clear context for selection, though it does not enumerate exclusions or comparisons to alternative 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, and the description adds value by specifying the return content: metadata, URL, dimensions, and labels. With no output schema, this return detail is useful behavioral context 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?

Two tightly written sentences with no fluff. The core purpose is front-loaded, the return values are listed, and the usage guidance is appended without 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 one-parameter read-only tool with full schema coverage and no output schema, the description covers what the tool does, what it returns, and when to use it. 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 coverage is 100%, with mediaId described as 'The media file ID.' The description reinforces that the tool works by ID but adds no format, example, or additional nuance beyond the schema.

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

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

States a specific verb and resource: 'Get details of a single media file by ID.' It clearly indicates this is a read operation targeting one media file, but it does not explicitly differentiate from the sibling view_media, which may serve a similar 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?

Gives clear context: 'Use this when the user references one specific media file by ID.' This implies it is for single-file lookups rather than listing or searching, but it does not name alternatives or exclusions such as list_media or view_media.

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. The description adds value by detailing what 'full details' means, including platform statuses, labels, media files, recurring schedule info, and metrics, which gives the agent a concrete picture of the response without contradicting 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 tight sentences. The first front-loads the verb and resource, then enumerates contents; the second provides usage context. No filler or repetition.

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

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

For a single-parameter read-only tool with annotations covering side effects, the description is complete. It tells the agent what the call achieves, what data comes back, and exactly when to use 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?

Schema coverage is 100% and postId is described as 'The post ID.' The description does not add extra semantic detail beyond referencing 'by ID,' so it stays at the baseline of 3.

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

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

The description states a specific verb ('Get'), a clear resource ('a single post by ID'), and enumerates the included details (platform statuses, labels, media files, schedule info, metrics), which distinguishes it from siblings like list_posts or 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 when to use: 'when the user references one specific post by its ID.' This is clear context, though it does not name alternatives or state when not to use it, 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?

The description goes far beyond the readOnly/destructive annotations, explaining critical interpretation behaviors: unsupported metrics are stored as 0 and must be reported as unavailable, linkClicks are tracked by BulkPublish and must not be summed with platform clicks, and bot/link-preview traffic is excluded. It also provides per-platform metric availability details, giving the agent essential context for interpreting results correctly.

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 lengthy but every sentence adds essential information for correct invocation and result interpretation. It is well-structured: purpose first, then critical caveat about supportedMetrics, then linkClicks semantics, then usage trigger. The IMPORTANT flag and clear segmentation prevent the density from becoming unwieldy.

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

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

With no output schema, the description does an excellent job of explaining return semantics: per-platform metric availability, zero-value handling, linkClicks placement outside `latest`, and total aggregation. It gives the agent everything needed to interpret the response correctly despite the absence of a structured output definition.

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 single parameter with 'The post ID to get metrics for,' so the description does not need to add much. It only clarifies that the post should be published, which is a marginal semantic addition. Baseline 3 is appropriate when the schema carries the documentation burden.

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

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

The description opens with a specific verb and resource: 'Get engagement metrics for a published post,' then enumerates the concrete metric types returned. It clearly distinguishes this tool from broader analytics or post-retrieval siblings by focusing on per-post engagement 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?

The description explicitly states when to use the tool: 'Use this when the user asks how a specific post performed (likes, views, engagement).' However, it does not explicitly contrast this with alternative analytics tools like get_analytics or view_analytics, so it stops short of full when-not-to-use guidance.

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

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

Annotations already disclose readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the 'optimal scheduling time' context and organization-level scoping, but does not explain how availability is calculated, what 'optimal' depends on, or what the return value looks like. With annotations present, this is acceptable but not enriched.

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 wasted words. The core action is front-loaded, immediately followed by a practical usage cue. 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 one-optional-parameter read-only tool with annotations covering safety, the definition covers what it does and when to use it. A minor gap is that it does not mention what the tool returns (e.g., a timestamp), but the name and usage make this largely inferable.

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 described in the schema. The description does not add any parameter-specific meaning beyond the schema, so it stays at the baseline score.

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 ('Get') and the resource ('the organization's next available queue slot'), explicitly linking it to 'next optimal scheduling time'. It is distinct from sibling tools like list_schedules and create_schedule because it concerns the next available slot rather than managing schedules.

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 an explicit trigger: 'Use this when the user asks when the next available scheduling slot is.' It offers clear context for when to select this tool, though it does not mention exclusions or alternatives—none are needed given the sibling list.

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

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

The description goes well beyond the readOnlyHint and destructiveHint annotations by explaining nuanced behavioral details: that channelSlots raise the effective channel limit by one, that unused slots are auto-canceled before renewal, and that per-slot autoRenews indicates renewal vs lapse at expiresAt. This is rich, non-obvious context that an agent would not infer from annotations alone.

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

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

The description is appropriately sized for the complexity of the return data. It front-loads the primary usage summary, then explains the channelSlots semantics, which are essential and non-obvious. Every sentence earns its place 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 output schema present, the description carries the full burden of explaining return values. It does so thoroughly by listing all major returned data categories and detailing the channelSlots structure, renewal behavior, and limits impact. Nothing critical is missing for an agent to understand what this tool provides.

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 parameters, and the description correctly makes no attempt to document parameters. With no parameters to explain, this baseline is appropriate and complete.

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

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

The description clearly states the tool's function: 'Check current account usage' and enumerates the specific resources it returns (post counts, scheduled post counts, channel counts, media storage usage, channelSlots). This is a specific verb+resource definition with enough detail to distinguish it from other tools like 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 description explicitly provides a usage condition: 'Use this when the user asks about plan limits or current usage.' This gives clear context for when to invoke the tool, though it does not name alternative tools or describe when not to use it.

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 useful return-field context (token status), but it claims 'all connected' channels while the active parameter defaults to true, meaning only active channels are returned unless explicitly filtered. This behavioral nuance is not disclosed in the description.

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 concise sentences with no filler. It front-loads the action and resource, then adds return fields and usage guidance. 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 list tool with one optional parameter and no output schema, the description covers purpose, return fields, and use case. The only notable gap is the unmentioned default active filtering, but the schema supplies that information.

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 is already well-documented with its default and meaning. The tool description adds no additional parameter guidance, 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 clearly states a specific verb and resource: 'List all connected social media channels' and enumerates supported platforms. It also specifies the returned fields (channel ID, platform, account name, token status), making the tool's scope evident. It does not explicitly differentiate from the sibling view_channels, so it falls short of a 5.

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

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

The description provides explicit usage context: 'Use this when the user wants to see which social accounts are connected.' This gives clear when-to-use guidance, though it does not mention when to use an alternative or provide exclusions.

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 readOnlyHint=true and destructiveHint=false, so the safe read nature is known. The description adds further behavioral detail by specifying the returned fields and that results are ordered by name, which goes beyond the structured 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 concise and well-structured: it opens with the core action, defines the resource type, lists the return payload, and closes with a direct usage statement. Every sentence adds value 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 zero-parameter read-only listing tool, the description covers the resource concept, output contents, ordering, and when to use it. The annotations cover safety, and no output schema exists, but the return fields are explicitly stated, so the agent has enough context to invoke it correctly.

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

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

The tool has zero parameters, and the schema coverage is effectively 100%. The description doesn't need to explain parameter behavior; the baseline of 4 applies because there is nothing missing for invocation.

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

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

The description states a specific verb and resource: 'List saved channel sets', and clarifies what they are ('named channel groupings for one-click multi-channel targeting'). It also specifies the return fields and ordering, making the tool's purpose unambiguous and distinct from related list operations like 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 an explicit usage condition: 'Use this when the user wants their saved channel groups'. It doesn't name alternative tools for contrast, but for a simple zero-parameter read-only list, this clear when-to-use guidance 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 covered. The description adds that labels are for 'tagging posts and media,' which is useful context, but it does not disclose additional behaviors such as pagination, ordering, filtering semantics, or return format.

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

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

The description is two short sentences with no wasted words. The purpose is front-loaded, followed by a clear usage cue, and every sentence contributes to understanding.

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 listing tool with one optional parameter and strong annotations, the description is nearly complete. It could briefly mention the optional type filter or expected return, but the schema covers the filter and the tool's simplicity reduces the risk of mis-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 single optional parameter is already fully documented. The description adds no further parameter-level meaning, which is acceptable because the schema carries the semantic burden.

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

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

The description uses a specific verb ('List') and a clear resource ('labels'), and explains that labels are used for tagging posts and media. This differentiates the tool from siblings like create_label, update_label, and delete_label by focusing on the read-only listing behavior.

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 phrase 'Use this when the user wants their post labels/tags' gives clear intent-based guidance for selecting the tool. It does not explicitly mention alternatives or exclusions, but the context is strong enough for an agent to know when this tool applies.

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

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

With annotations already declaring readOnlyHint=true and destructiveHint=false, the description credibly adds useful behavioral context by naming the returned metadata (URLs, dimensions, labels) and the optional search/pagination behavior. No contradictions or misleading safety signals.

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, front-loaded with the tool's main function and output, followed by one clear usage pointer. Every clause earns its place with no repetition 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 listing tool with fully documented parameters, annotations covering safety, and no output schema, the description is complete: it states what is returned, the filtering/pagination options, and the intended use case. Nothing critical is missing.

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

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

Schema description coverage is 100%, so all four parameters are already documented. The description only restates 'search' and 'pagination' conceptually without adding details beyond the schema, matching the baseline-3 expectation.

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: it lists uploaded media files, with optional search and pagination. It distinguishes itself from singular media accessors like get_media by emphasizing the plural listing behavior, though it does not explicitly name sibling tools to contrast against.

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

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

It gives an explicit usage condition: 'Use this when the user wants a list of their uploaded media files.' It does not state when not to use it or mention alternatives, but for a straightforward listing tool this 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 mark read-only and idempotent, and the description complements them with operational behavior: disabled platforms are still listed with enabled=false and reason, off rejects writes with 403, connect_off blocks new connections but keeps existing channels publishing, and variants are gated separately. This goes well beyond the annotation hints.

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 every sentence adds operational value, from the state model to the LinkedIn-specific variant behavior. It is front-loaded with the core purpose before diving into edge cases.

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

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

With no output schema, the description carries the burden of explaining return semantics, and it covers states, error codes, variants, and scheduling behavior. For a parameterless read-only tool, this is sufficient for an agent to call it correctly and interpret responses.

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 has zero parameters, so there is nothing to document; baseline 4 applies. The description instead focuses on output semantics (enabled flag, reason, variants object), which is the relevant information for invoking the tool.

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 action and resource: 'List every social platform BulkPublish supports and whether it is currently available.' Clearly distinguishes from sibling list_channels by scoping to platforms and their availability.

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

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

Explicitly tells when to call it: before telling a user they can connect a platform or scheduling a post, and when a connect/publish attempt failed with PLATFORM_DISABLED. It also explains conditions like 'off' and 'connect_off' so an agent can decide correctly. No explicit alternative is named, but the use cases are 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?

Even though annotations already declare readOnlyHint=true, the description adds substantive behavioral details: results are paginated, include platform statuses and metrics, and are ordered newest-first by publishedAt, else scheduledAt, else createdAt. This goes well beyond what annotations convey.

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

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

Three sentences with no wasted words: the first states the action and filters, the second covers return behavior and ordering, and the third gives usage context. Information is front-loaded and the structure is easy to scan.

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 11 optional parameters and no output schema, the description covers the essential behavioral aspects: filter types, pagination, ordering, and the nature of returned data (platform statuses and metrics). It doesn't enumerate every output field, but what it provides is sufficient for most calling scenarios.

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 fully documents all 11 parameters. The description summarizes filters (status, search text, date range, channel, label) but does not add deeper semantics beyond grouping what the schema already describes.

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 ('List posts') and resource, and enumerates the optional filters (status, search text, date range, channel, label). The phrase 'as raw data (not the visual dashboard)' distinguishes it from the sibling view_posts, making the tool's identity 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?

The description explicitly says 'Use this when the user wants to browse, filter, or check the status of existing posts as raw data' and contrasts with 'the visual dashboard'. It provides clear context and an exclusion, but doesn't name the alternative sibling (view_posts) directly.

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

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

Beyond the readOnlyHint and destructiveHint annotations, it reveals that feeds are polled on a fixed 15-minute cadence and that new items are automatically rendered into posts. It also discloses the exact output contract, including the meaning of fieldMapping (null = default) and the presence of lastCheckedAt and lastError, which is especially valuable given 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?

The definition is compressed into three purposeful sentences: resource definition, return fields, and usage instruction. There is no repetition of the title or annotation boilerplate.

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

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

With no output schema, the description takes on the responsibility of describing the return value, and it names all relevant fields and their semantics. There are no required parameters or preconditions to document, so nothing needed 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 input schema has zero properties, so there are no parameters for the description to clarify. With 0 params the baseline is 4, and the description adds no unnecessary parameter commentary.

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-object statement, 'List RSS autopost feeds,' and defines the resource as RSS/Atom feeds polled every 15 minutes whose new items become posts. The return-field enumeration makes clear this is a read-only listing tool, and the 'autopost' term distinguishes it from generic list_posts/list_channels 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?

It explicitly tells the agent when to call it: 'Use this when the user wants their RSS autopost feeds.' It doesn't spell out when-not-to-use or name alternatives like create_rss_feed/update_rss_feed/delete_rss_feed, but the sibling names make those distinctions obvious.

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 as read-only and non-destructive. The description adds useful context by listing the concrete return fields and noting that the same schedules appear in the web app. It does not disclose ordering or pagination, but that is acceptable for a zero-parameter read 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?

Three short sentences with the main action and return fields front-loaded. The web-app context sentence is mildly nonessential but adds useful user-facing context. No fluff 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 with no output schema, this is effectively complete. The description states what the tool returns, gives user-facing context, and provides a clear use condition. Missing pagination details are minor given the tool's simplicity.

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 is empty with 100% schema description coverage, so there are no parameters that require explanation. Baseline 4 applies for zero-parameter tools, and the description appropriately focuses on return value semantics instead.

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 the exact action and resource: 'List all recurring post schedules.' It enumerates the returned fields, which makes the operation unambiguous, and clearly differentiates this from list_posts and schedule mutation tools like create_schedule/update_schedule.

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

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

Gives explicit trigger context: 'Use this when the user wants their recurring posting schedules.' It does not name an explicit alternative or when-not condition, but there is no close sibling for listing schedules, so the context 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?

Beyond the annotations, the description discloses meaningful behavioral details: the post is queued for all target channels, requires a specific permission, returns 403 APPROVAL_REQUIRED for contributors, and implicitly approves pending/rejected posts when an approver publishes. No annotation contradiction 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?

The description is four sentences long, front-loaded with the primary action, and every remaining sentence adds essential context—permission requirements, alternative workflow, and implicit approval behavior. There is no filler or repetition of schema fields.

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 tool without an output schema, the description fully covers when to use it, what happens on success, permission constraints, error behavior, and the alternative approval flow. No additional context is needed for an agent to invoke 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 only parameter, postId, is already documented as 'The post ID to publish.' The description reinforces that the post must be an existing draft or scheduled post, but this adds limited new 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 opens with a specific verb and resource: 'Publish a draft or scheduled post immediately.' It clearly distinguishes this from sibling tools like create_post, update_post, and publish_story by scoping it to existing posts that need immediate publication.

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 ('when the user wants to publish an existing draft or scheduled post right now') and gives an alternative path for contributors lacking post:publish permission, routing them to create/update with requestApproval and a teammate approval. This directly addresses when-not-to-use and the correct 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 annotations already indicate readOnlyHint=false and openWorldHint=true, so the mutating/external nature is covered. The description adds no further behavioral context such as immediate visibility, auth requirements, failure behavior, or effects on the original post, providing minimal value 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?

The description is two short sentences with no filler. The action is front-loaded and the usage condition immediately follows, so 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 two-parameter tool with a fully documented schema and no output schema, the description names the action, target platforms, and invocation trigger. Nothing essential for an agent to select and call the tool correctly is missing.

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

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

Schema description coverage is 100%: both postId and platform have descriptions, and platform has a clear enum. The description only mirrors the schema's platform names without adding extra parameter meaning, 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 states a specific verb ('Publish'), resource ('a post as a story'), and platform scope ('Facebook or Instagram'). The phrase 'as a story' clearly distinguishes this from publish_post and other content tools in the sibling list, and the use-case sentence reinforces the exact 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?

'Use this when the user wants to post an Instagram/Facebook story' explicitly states the trigger condition. It does not name alternative tools or exclusions, but the context is clear enough for an agent to know when to select it.

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 the permission requirement (post:approve), the resulting state change (returns to draft with approvalStatus 'rejected'), the author notification, and the ability to edit and resubmit. Error codes 400/403/404 are also listed. This goes well beyond the annotations, which only state readOnlyHint=false and destructiveHint=false.

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

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

The description is well-structured with front-loaded scope, then permission, effects, errors, and usage guidance. It is slightly redundant because the first and last sentences both mention 'awaiting team approval,' but every sentence otherwise contributes value.

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 and sparse annotations, the description covers the essential context: authorization, exact state transition, follow-up workflow, and all relevant error cases. An agent can confidently invoke this tool correctly without further information.

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?

Input schema coverage is 100%, and both postId and reason already have detailed descriptions in the schema. The description adds no new parameter-level detail, so it does not need to compensate for schema gaps; 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 'Reject a post awaiting team approval,' a specific verb+resource+scope that clearly defines the operation. It distinguishes this from sibling tools like approve_post and publish_post by the 'awaiting team approval' condition.

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: 'when the user (an owner/admin/approver) wants to reject a post awaiting team approval.' It gives role context but does not explicitly name alternatives or exclusion cases, leaving minor room for improvement.

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 behavior beyond the annotations: it only retries failed platforms, leaves succeeded platforms untouched, and refuses to retry unconfirmed platforms unless republish is true. It also surfaces a specific error code and the duplicate-post risk, which is critical for an operation with openWorldHint=true and no destructiveHint.

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

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

The description is front-loaded with the core purpose and then adds only necessary edge-case behavior. Every sentence earns its place — the failed-platform scope, the unconfirmed exception, the error handling, and the usage guidance are all relevant and non-redundant.

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

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

For a two-parameter operation with complete schema descriptions, the description fully covers call prerequisites, side effects, failure modes, and user-interaction steps. It does not have an output schema, but the behavior a caller needs to handle is disclosed, including the UNCONFIRMED_REQUIRES_REPUBLISH error.

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 postId and republish in detail, including duplication risk and default behavior. The tool description adds some context about republish but mostly reinforces what the schema already states, so it meets the baseline without going beyond it.

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

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

The description names a specific verb and resource — 'Retry publishing a failed or partially failed post' — and immediately distinguishes itself from general publishing tools by scoping to failed platforms only. It clearly differentiates from siblings like publish_post and approve_post by focusing on retrying already-attempted 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 explicitly says when to use the tool: 'Use this when a post failed on some platforms and the user wants to retry just those.' It also gives when-not-to-retry conditions, including the unconfirmed-platform caveat and the 400 error path, instructing the agent to ask the user before setting republish.

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

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

Annotations already cover read-only, non-destructive, and open-world behavior, so the description does not need to repeat those. It adds context about the suggestions being from a connected channel while drafting a post, but does not disclose details like result limits, pagination, or response structure. This is fine given the annotations, but the description adds only modest behavioral 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 three sentences long, all of which contribute value: the core action, the use case, and the specific trigger for use. It is front-loaded with the main purpose and avoids verbose detail. Minor redundancy exists between 'on a channel' and 'from a connected channel', but it is not problematic.

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

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

This is a simple read-only tool with two required parameters fully described in the schema and no output schema. The description adds enough context about when and why to use it. It does not describe the return format, but for a suggestions lookup this is not a critical omission given the simplicity.

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 'query' and 'channelId' already described. The description does not add additional meaning beyond the schema, which keeps this at the baseline for high 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 states a specific verb ('Search') and a specific resource ('@mention suggestions on a channel'), making the tool's purpose clear. It also distinguishes itself from the get_/list_/view_ sibling tools by focusing on mention suggestions rather than general content retrieval. The wording is not tautological and adds useful context about finding users/pages.

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 you need @mention suggestions from a connected channel while drafting a post.' It does not mention alternative tools or provide exclusions, but the use case is clear enough for an agent to select it appropriately.

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 meaningful behavior beyond annotations: partial update semantics ('at least one field is required') and the specific 409 DUPLICATE_NAME collision failure. Annotations already signal read/write/destructive/idempotent traits, and the description supplements them without contradiction.

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 front-load the core operation and error behavior. Every clause adds usable information with no repetition of schema descriptions.

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 3-parameter update tool, the description covers use case, partial-update constraint, and error condition; annotations cover safety properties. Success return value is not described, but that isn't essential for an agent deciding whether to call 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?

Schema coverage is 100%, so the baseline is 3; the description adds value by clarifying the at-least-one-field requirement that the schema itself doesn't express (schema only requires setId). It also ties 'name and/or channels' to the update intent.

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 ('Update'), names the resource ('channel set'), and specifies the mutable fields ('name and/or channels'). It also states the partial-update semantics, which distinguishes it from create/delete channel set operations among 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 'Use this when the user wants to rename a channel set or change its channels,' giving clear invocation context. It doesn't name the create/delete alternatives or state when not to use this tool, but the use-case phrasing is specific 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 supply idempotentHint=true, readOnlyHint=false, and destructiveHint=false, so the description does not need to repeat those. It adds the useful context that only name and color can be updated on an existing label. However, it does not describe what happens on success, what the response contains, or error behavior, so it stays at the baseline for annotation-covered behaviors.

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 with no wasted words. The first sentence states the action and scope, and the second sentence provides the usage trigger. Information is front-loaded and 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 update tool with one required parameter, 100% schema coverage, and adequate annotations, the description covers the core usage context. The main omission is what happens after a successful update (e.g., return value or side effects), but given the absence of an output schema and the tool's simplicity, this is a minor gap rather than a blocking one.

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 in the schema. The tool description mentions 'name or color', which loosely maps to two parameters, but it does not add additional semantic meaning beyond what the schema already provides. The baseline of 3 is appropriate.

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

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

The description states a specific verb ('Update') and resource ('existing label') and narrows the action to changing its name or color. It is clear, though it does not explicitly contrast itself with create_label or delete_label beyond the word 'existing', so it falls short of full sibling differentiation.

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

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

The description gives an explicit trigger condition: 'Use this when the user wants to rename or recolor a label.' This tells an agent when to select the tool. It does not provide exclusion criteria or mention alternatives, but the trigger is sufficiently clear for a focused update tool.

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

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

Annotations already signal mutability (readOnlyHint=false) and idempotency (idempotentHint=true), so the description's burden is reduced. It adds genuinely useful behavior beyond the annotations: 'editing a failed/partial post resets it to draft' and the status-transition rules (draft unschedules; scheduled requires a future scheduledAt and a channel). No contradiction with the annotations — the reset-to-draft behavior is consistent with a mutating, idempotent update.

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 with no fluff; purpose is front-loaded, followed by the editability constraint, the status-transition rule, and a routing cue. Each sentence earns its place. Slightly compressed but well-organized given the tool's high complexity.

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

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

For a high-complexity tool (11 params, deeply nested platform-specific objects) with an exhaustive schema and no output schema, the description covers purpose, editability constraints, state transitions, and sibling routing. It doesn't describe the return value, which is acceptable given no output schema exists, and it could mention get_post for retrieval after editing, but the gaps are minor against a very rich 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%, so the baseline is 3 — the schema already documents every parameter in detail (status enum semantics, platform-specific nesting, linkTrackingOverride null behavior). The description adds only a high-level status-transition summary that roughly mirrors the schema's own status description. It correctly doesn't duplicate schema detail, which is appropriate at this parity.

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 ('Update'), a resource ('existing post'), and enumerates what can change (content, schedule, media, labels, status, platform-specific settings). It differentiates from siblings by scoping to existing posts and by naming publish_post as the alternative for immediate publishing — an agent can distinguish this from compose_post/create_post and publish_post without opening schemas.

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

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

Gives an explicit 'Use this when the user wants to edit an existing post' directive and names publish_post as the alternative for immediate publishing. It also documents the editability constraint (only draft, scheduled, failed, or partial posts). It does not explicitly point to create_post/compose_post for new posts, though the 'existing post' scoping implies the boundary — a small gap.

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

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

The description goes beyond annotations by disclosing the re-baseline side effect when feedUrl changes: check state resets, only items published after the change are posted, and backlog flooding is avoided. This directly informs agent reasoning about a mutating side effect. It also states 'partial update,' which tells the agent that omitted fields retain existing values. 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?

Three sentences, front-loaded with the core action, followed by a behavioral caution and a use-this-when clause. No redundant or filler content; the re-baseline warning justifies its length.

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 8 parameters, no output schema, and annotations that already mark this as a non-read-only, non-destructive, idempotent operation, the description covers the key side-effect (re-baseline) and intended triggers. The schema handles parameter-level details; the description adds invocation context and a caution that prevents misuse. No critical gaps for correct selection/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 covers 100% of parameters, so baseline is 3. The description adds the 'partial update' semantic, clarifying that only explicitly provided fields are modified, and repeats the feedUrl re-baseline consequence. Though the schema already documents feedUrl's re-baseline, the partial-update framing provides cross-cutting meaning not present in any individual parameter description.

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 ('Update') and resource ('RSS autopost feed'), clarifies scope with 'partial update,' and differentiates from create/delete/list siblings by naming the intended use cases (change, pause, re-point).

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 trigger: 'Use this when the user wants to change, pause, or re-point an RSS autopost feed.' However, it does not explicitly mention alternatives (e.g., create_rss_feed for new feeds, delete_rss_feed for removal), so the guidance is clear but not exhaustive.

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

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

The description adds a useful behavioral detail beyond the annotations: 'The next run time is recomputed by the server when timing changes.' This is a non-obvious server-side side effect. It does not contradict the idempotentHint or destructiveHint 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 concise and front-loaded with the core action, followed by the changeable aspects, a relevant side-effect, and usage guidance. The final usage sentence is slightly redundant with the opening, but 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 11 parameters with full schema coverage and annotations providing safety/idempotency signals, the description covers the key operational points: what can change, when to use it, and how timing changes affect scheduling. It could mention explicit alternatives, but nothing essential for invoking the 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 each parameter is already documented. The description groups parameters into categories like 'frequency/timing' and 'media,' which provides a high-level overview but adds little 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?

The description clearly states the action and resource: 'Update an existing recurring schedule' and enumerates the modifiable aspects (name, content template, frequency/timing, timezone, media, active status). It is distinct from create/delete/list siblings, though it does not explicitly name an alternative tool.

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 usage direction: 'Use this when the user wants to change a recurring schedule.' It does not provide when-not-to-use guidance or name create_schedule/delete_schedule as alternatives, but the context is clear.

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

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

With no meaningful safety annotations beyond readOnlyHint=false and destructiveHint=false, the description carries the behavioral burden. It discloses that the file is stored, lists supported formats, sets a 100MB limit, and specifies the exclusive-or relationship between url and filePath. It could add what the API returns (e.g. media ID) or overwrite/idempotency behavior, but the provided details go beyond the 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?

Four sentences with no filler: purpose first, then storage context, format/size constraints, exclusivity rule, and a final usage trigger. Every sentence earns its place and the most actionable guidance appears early.

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 3-parameter, no-output-schema tool, the description covers the essential call constraints: source, format, size, exclusivity, storage destination, and intended use. The main gap is the lack of any hint about the return value (e.g. whether it returns a media ID or URL), which is more important given there is no output 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%, so the baseline is 3. The description adds genuine value by explaining the mutual exclusivity of url and filePath, which is not captured in the property descriptions, and by constraining acceptable inputs via formats and size. This justifies one point above baseline.

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

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

The description clearly states the verb and resource: uploading a media file from a URL or local path into BulkPublish for use in posts. It also gives supported formats and a size limit, making the scope concrete. However, it does not explicitly differentiate this tool from siblings like create_media_upload or create_multipart_upload, so it misses the top-tier sibling-distinguishing evidence.

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 context: 'Use this when the user provides an image/video to attach to a post.' It also states the either-url-or-filePath constraint. It does not name alternatives or give explicit when-not-to-use guidance, so it stops one step short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context about the interactive/visual nature of the dashboard, which goes beyond the structured annotations without contradicting 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 concise sentences, front-loaded with the tool's purpose and the key use-case differentiator. Every clause adds value, and the sibling preference is placed at the end without bloat.

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

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

With an output schema present, fully documented parameters, safety covered by annotations, and explicit sibling differentiation, nothing an agent needs to call this tool correctly is missing. The description is complete for its complexity.

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

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

Schema description coverage is 100%, with both parameters fully documented including defaults and format examples. The description only mentions 'date range' generically, adding little beyond the schema, 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?

States a specific verb ('Open') and resource ('interactive analytics dashboard'), and enumerates concrete contents (totals, status breakdown, per-platform stats, daily post counts). Clearly distinguishes it from the sibling get_analytics by emphasizing the visual/interactive aspect.

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

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

Explicitly says to use this tool when the user wants an interactive analytics dashboard and names get_analytics as the alternative it should be preferred over for a visual view. The when-to-use guidance is direct 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 mark the tool as read-only and non-destructive. The description adds useful behavioral context beyond that: the tool presents an interactive view and surfaces specific status information (platform, account, connection/token). No contradiction with 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?

Two sentences carry the full meaning with no filler. The core purpose and contents are front-loaded in the first sentence, and the second sentence directly reinforces the usage condition.

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 an output schema, the description provides all necessary context: what the user sees and when to invoke it. Nothing essential is missing for an agent to select and 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 tool has zero parameters and schema coverage is complete, so the baseline is 4. The description does not need to clarify parameters because there are none, and it does not introduce any misleading parameter-related information.

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') with a clear resource ('connected social channels') and enumerates the view's contents: platform, account, and connection/token status. It also signals the view is interactive, which distinguishes it from sibling tools like 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?

It explicitly states when to use the tool: 'when the user wants an interactive view of their connected channels.' It does not explicitly name alternatives or exclusions, but the context of siblings like list_channels makes the intended use reasonably clear.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the interactive and visual nature of the tool, which is useful, but does not disclose any further behavior such as response format or interaction mechanics. Given the annotations, this is adequate.

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, front-loaded sentences. The action and purpose appear first, and the usage guidance follows immediately. No filler or redundant restatement.

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 simple, has one optional parameter, a complete output schema, and safety annotations. The description covers when to use it and what the user experiences. It is sufficient for correct invocation, though it could briefly contrast with list_media for even stronger sibling differentiation.

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, has a full description in the schema (default 30). The tool description adds no additional parameter-level detail, but with 100% schema coverage the baseline of 3 is appropriate.

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

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

The description uses a specific verb ('Open') and resource ('interactive gallery of uploaded media files'), and distinguishes itself from sibling tools like list_media by emphasizing the visual, thumbnail-based browsing experience. This is immediately actionable and 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?

The description explicitly states when to use the tool: 'Use this when the user wants to browse their media library visually.' It does not name alternatives like list_media or state when not to use it, but the visual browsing context is clear enough to route an agent appropriately.

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 useful context about what is displayed (status, schedule, channels) and that the view is interactive, but it does not disclose additional operational behavior such as result ordering or limitations. This is acceptable but not exceptionally rich 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?

Two sentences deliver all essential information: what the tool does, the key filter option, and the alternative tool. The usage guidance is front-loaded and there is no wasted wording.

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

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

For a simple read-only listing tool with zero required parameters, full schema coverage, an output schema, and safety annotations, the description is complete. The agent has enough context to invoke it correctly and to distinguish it from list_posts.

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 (limit and status) are already documented in the input schema. The description reinforces that status can be used as an optional filter, but adds no new semantic detail beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states it opens an interactive list of posts with status, schedule, and channels, and explicitly differentiates itself from list_posts by emphasizing the visual dashboard aspect. The verb 'open' plus the resource 'posts' makes the action specific and 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?

It explicitly tells the agent when to use this 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 clear routing guidance without requiring schema inspection.

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 safety. The description adds that the tool opens an interactive/visual view, which is useful context, but does not elaborate on what the user sees or how the view behaves. This is acceptable but not rich.

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 the core purpose front-loaded and the usage condition in the second sentence. Every word adds value; 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 zero-parameter, read-only view tool with an output schema present, the description covers what the tool shows and when to use it. It could briefly contrast with get_quota_usage, but the core information an agent needs to select and invoke this tool correctly is 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?

The tool has zero parameters, and the input schema is empty with 100% coverage. There is no parameter information needed, so the baseline of 4 applies; the description appropriately focuses on behavior instead of 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 states a specific action ('Open an interactive view') and a specific resource ('current account usage') with concrete details (daily/monthly post counts, channel counts, media storage). This clearly distinguishes it from the sibling get_quota_usage 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?

Explicitly states when to use the tool: 'when the user wants a visual view of their plan usage.' It does not name alternative tools or exclusions, but the visual cue and scope provide clear usage context relative to siblings like get_quota_usage.

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