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

With no annotations, the description carries the full burden. It clearly conveys the destructive nature of the action ('Cancel') and the precondition ('pending'). However, it does not state whether cancellation is reversible, what happens if the reel has already been posted, or any other 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 a single concise sentence with no filler. The core action and input source are front-loaded, and every word contributes to understanding the tool.

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

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

For a one-parameter tool with no output schema, the description covers the action, required input, id source, and scheduling state. It could mention what result to expect on success or failure, but that is not essential for correct selection and invocation.

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

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

The schema only says 'id' is a string with no description. The tool description compensates by explaining that id refers to a scheduled reel and pointing to the tools that produce valid ids, which is valuable for correct 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 uses a specific verb ('Cancel'), a clear resource ('pending scheduled reel'), and identifies exactly where the id comes from ('from schedule_reel or list_scheduled_posts'). This clearly distinguishes it from the sibling scheduling and listing tools.

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

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

It gives clear usage context: use it to cancel a pending scheduled reel, and the required id is obtained from schedule_reel or list_scheduled_posts. It does not explicitly list exclusions or alternative tools, but the intended scenario is unambiguous.

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

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

With no annotations, the description carries the full burden. It clearly discloses that the operation is permanent ('This cannot be undone') and destructive ('Permanently delete'). It does not mention possible cascading effects or auth requirements, but the most critical behavioral trait is well communicated.

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

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

Two sentences with no redundant phrases. The primary action is front-loaded, and the crucial caveat and alternative follow immediately. Every part 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-parameter delete tool with no output schema, the description covers purpose, irreversibility, and the sibling alternative. It does not describe the response format or error behavior, but those are less critical for a straightforward action.

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

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

Schema description coverage is 0%, so the description must compensate. It does not explain comment_id's format, source, or how to obtain it; it only implies the parameter refers to the comment being deleted. The parameter name is self-explanatory but no added semantics are provided.

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 ('Permanently delete a comment') and explicitly differentiates it from the sibling hide_comment. An agent can immediately understand the tool's core function and how it differs from related 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 explicitly names the alternative (hide_comment) and states the condition that selects it ('if you just want to reduce visibility'). This gives clear when-to-use / 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?

No annotations are provided, so the description alone must carry behavioral disclosure. 'List' implies a read-only operation, but the description does not mention pagination, return format, authentication, rate limits, or whether only top-level comments are returned.

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

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

One short sentence with no filler and the core scope front-loaded. It communicates the tool's job efficiently.

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 read tool, this may be minimally sufficient, but the lack of an output schema and any mention of comment fields, ordering, or pagination leaves an agent without important retrieval expectations.

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 media_id as 'Instagram media id' with 100% coverage. The description's 'on a media item' reinforces the connection but adds no further semantic detail.

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 ('comments on a media item'). It is unambiguous and visibly distinct from sibling tools that reply to, hide, or delete comments.

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 intended usage is implied: use it when you want to retrieve comments for a media item. However, it does not explicitly state exclusions or alternatives, so the agent must infer the boundary against siblings.

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

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

With no annotations, the description must carry behavioral transparency. The verb 'Get' implies a read-only operation, and the description discloses conditional metric availability for video/reels. However, it does not mention authentication requirements, errors, invalid media_type behavior, or the shape of the response, leaving some behavioral burden unmet.

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

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

A single, front-loaded sentence with no filler. It communicates the core action, the target resource, and the metric details efficiently.

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 read tool, the description covers the purpose and the key conditional behavior. It could mention the return shape or how media_id should be obtained, but the schema already says media_id comes from list_media and the metric list is explicit.

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 reinforces the media_type dependency and the scope of insights, but it does not add significant semantic value beyond the schema's already detailed parameter descriptions.

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 ('Get'), a specific resource ('performance insights for a specific media item'), and enumerates the metrics returned. It is clearly distinguishable from siblings like get_comments or post_el.

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

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

It states the context for using the tool: retrieving insights for a specific media item, and notes that media_type affects which metrics are valid. It does not explicitly name alternatives or when-not to use it, but the conditions are 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that hidden comments remain visible only to the author and account, and that the action is reversible — both essential behavioral traits beyond what the name implies.

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

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

Two short sentences with no filler. The core action is front-loaded, and the critical visibility/reversibility detail is delivered immediately after, making every word earn its place.

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

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

For a simple two-parameter tool with no output schema, the description covers the core action, the effect on visibility, and reversibility. It lacks explicit alternative guidance, but the essential context an agent needs to invoke the 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 schema provides no descriptions for parameters, so the description must compensate. 'Hide or unhide' clarifies the toggle behavior of the 'hide' boolean, but it does not explain the required 'comment_id' field, which is left to inference from its name.

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 plus resource — 'Hide or unhide a comment' — which is unambiguous. The added visibility rule and reversibility note distinguish it from delete_comment, making the tool's purpose 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?

The description implies usage through the word 'reversible', suggesting this is for temporarily hiding rather than permanently deleting comments. However, it does not explicitly name alternatives like delete_comment or state conditions for choosing this tool over them.

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 annotations, the description carries the burden of disclosing behavior. 'List' conveys a non-mutating operation and 'with basic engagement counts' hints at return content, but it does not mention ordering, pagination, rate limits, or whether this requires special permissions. For a simple list tool 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?

The description is one efficient sentence, front-loaded with the primary action ('List recent media') followed by concise clarifiers for scope and return content. Every element earns its place with no redundancy.

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

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

For a single-parameter list tool with no output schema, the description identifies the resource and return value type but does not specify the output shape or pagination behavior. It is usable, but an agent might still be unsure about the exact media object fields beyond engagement counts.

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

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

Schema description coverage is 0%, so the description needed to explain the 'limit' parameter. It does not mention limit at all, leaving the agent to rely solely on the schema's min/max/default metadata, which is clear but not supplemented by the 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?

Description states a specific verb ('List'), a specific resource ('recent media on the connected Instagram account'), and names the media types included. It is clearly distinct from siblings that create/schedule content or return insights for a single media item.

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 makes the read-only listing purpose obvious, which implies use when the agent needs recent media and engagement counts. However, it does not explicitly say when to prefer this over siblings like get_media_insights or list_scheduled_posts, leaving routing to inference.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clarifies that the tool lists current statuses and enumerates possible values, which is useful, but it does not disclose whether the operation is read-only, whether results are ordered, or what the actual return shape looks like.

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 a single efficient sentence that names the resource and the key status values without filler. Every word contributes to agent understanding, and the status list is front-loaded after the primary purpose.

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 list tool with no output schema, the description conveys the essential behavior and expected status output. It is slightly incomplete because it does not describe the result format or any ordering/filtering behavior, but these 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 has zero parameters, so the baseline is 4 because there is no parameter meaning to document. The description appropriately focuses on what the tool returns rather than parameters, and no parameter information is missing.

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 resource ('scheduled reels') with an explicit status enumeration. It is distinguishable from siblings like schedule_reel and cancel_scheduled_post, though the slight mismatch between the tool name 'scheduled_posts' and description 'scheduled reels' introduces minor ambiguity.

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

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

The description makes its scope clear by listing all scheduled reels and statuses, which implies when an agent would use it. However, it provides no explicit guidance about when to choose this tool over alternatives such as list_media or cancel_scheduled_post, and no exclusions are stated.

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 annotations provided, the description carries the full behavioral burden. It discloses a critical behavior: Instagram fetches the image directly from a publicly reachable JPEG URL. This is valuable operational context, though it does not cover side effects, authentication, or 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?

Two tightly written sentences with no filler. The core action is stated first, and the critical URL constraint is front-loaded immediately after.

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 low-complexity, two-parameter tool without an output schema, this description covers the essential operational details: what is published, where it is published, and how the image must be provided. Some potential details like auth or rate limits are absent, but the core usage is adequately specified.

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

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

Schema description coverage is 0%, so the description must compensate. It adds crucial meaning to image_url by specifying it must be a publicly reachable JPEG, which goes beyond the schema's plain 'format: uri'. The caption parameter is left to the schema, but the most important parameter is well explained.

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: 'Publish a single photo to the feed.' This clearly distinguishes it from sibling tools like post_story and post_reel, which target different formats and surfaces.

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 'to the feed' and 'single photo' provides clear context for when this tool applies, especially alongside post_story and post_reel. It does not explicitly name alternatives or exclusions, but the intended use is clear enough for an agent to select it correctly.

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

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

Despite no annotations, the description discloses several critical behaviors: it blocks while Instagram processes the video, processing usually takes 30 seconds to 2 minutes, progress is reported, and local files are uploaded directly to Meta's servers. This is substantial behavioral context beyond the schema.

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

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

The description is three concise sentences with no filler. It front-loads the primary action, then covers the key parameter constraint, and finally the blocking/progress behavior. 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 tool with four optional parameters and no output schema, the description gives enough to call it correctly: the video source constraint, the blocking behavior, and progress reporting. The remaining parameter meanings are covered by 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?

The description adds critical meaning beyond the schema by requiring exactly one of video_url or video_path and explaining the difference: video_url must be publicly reachable, while video_path is a local file requiring no hosting. This compensates well for the 50% schema coverage, though caption semantics are left largely to 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 opens with the specific verb 'Publish' and resource 'a Reel,' making the tool's purpose immediately clear. It also differentiates from siblings by emphasizing immediate publishing and blocking behavior, distinguishing it from schedule_reel and post_story.

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 clearly conveys when to use this tool: to publish a Reel now, not schedule it. It does not explicitly mention alternatives like schedule_reel or post_story, but the context and blocking behavior make the intended usage 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?

No annotations are present, so the description carries the full transparency burden. It does add useful behavioral context by specifying '24-hour' ephemerality and the exclusive input rule, but it omits auth/permission requirements, expected return value, and behavior when the exactly-one constraint is violated.

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

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

A single, front-loaded sentence with no filler. Every word contributes either the core action, the content type, the input sources, or the exclusivity constraint.

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

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

For a simple two-parameter tool, the description covers the essential invocation constraint, but without annotations or an output schema, it leaves out what happens after publishing and how the caller learns the result. It is minimally viable but not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It clearly maps the two parameters to image and video URLs and adds the critical constraint that exactly one must be provided, which the schema does not express.

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'), a distinct resource ('24-hour story'), and the two acceptable input sources (image or video URL). The term 'story' clearly separates it from sibling tools like post_image and post_reel, so an agent can identify what this tool does immediately.

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

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

The description provides no guidance on when to use this tool instead of post_image, post_reel, or schedule_reel. The parenthetical 'provide exactly one' is a parameter constraint, not tool-selection context or an explicit when/when-not 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?

No annotations are provided, so the description carries the full burden. It does disclose two meaningful behavioral traits: the reply is publicly visible and it is scoped to the account's own media items. It stops short of disclosing side effects (e.g., the reply appearing in the public thread, persistence after the original comment is hidden), auth expectations, or failure conditions such as disabled comments or invalid comment_id.

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

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

A single ten-word sentence front-loads the verb and the key scope qualifiers ('Publicly', 'one of the account's media items') with zero filler. Every word earns its place for a tool this simple.

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: 2 required scalar params, no output schema, no annotations. The description covers the essentials — action, visibility, and ownership scope — well enough for an agent to select and invoke it. Remaining gaps (how comment_id is sourced, failure behavior) are minor and partly inferable from sibling tools like get_comments.

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

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

Schema description coverage is 0%, so the description must compensate. It adds some meaning beyond the schema by scoping comment_id to a comment on the account's own media, and message as the public reply content. It does not, however, tell the agent where to obtain comment_id (e.g., from get_comments) or provide value-format guidance beyond the schema's type and maxLength.

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 ('reply') with a specific resource ('a comment on one of the account's media items'), and the qualifier 'publicly' sharpens the meaning. It is clearly distinguishable from siblings like get_comments, hide_comment, and delete_comment, though it does not explicitly name any alternative.

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

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

The trigger condition is implied: use this when a public response to a user's comment on the account's media is needed. However, there is no explicit guidance on when not to use it (e.g., for moderation use hide_comment/delete_comment) and no mention of prerequisites or restrictions.

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 annotations, the description carries the full burden and it excels: it explicitly discloses that scheduling only fires while the MCP server remains running, that it is not durable/cloud scheduling, and that it is best for same-session/same-day use. This is a critical behavioral caveat an agent must know before invoking 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 and front-loaded: purpose first, then required parameters, then the critical limitation in a clearly marked paragraph. Every sentence earns its place without 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 five-parameter tool with no annotations and no output schema, the description covers the required parameter, the one-of constraint, the time format, and the main behavioral caveat. It doesn't describe the response/confirmation an agent should expect, and it leaves the two optional boolean/string params implicit, which is a minor completeness 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 only 20%, and the description compensates by adding the crucial 'exactly one of video_url or video_path' constraint and a concrete ISO 8601 example for scheduled_time. It doesn't elaborate on caption or share_to_feed, but those are reasonably self-explanatory from their names and 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?

Description states a specific verb and resource: 'Schedule a Reel to publish at a future time.' This clearly distinguishes it from immediate-publish siblings like post_reel and from management tools like cancel_scheduled_post.

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

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

It gives clear invocation guidance ('Provide exactly one of video_url or video_path, plus an ISO 8601 scheduled_time') and strongly frames when it is appropriate via the same-session limitation and the 'laptop is off' counterexample. It doesn't explicitly name an alternative tool for immediate posting, so it stops short of full 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?

With no annotations provided, the description carries the full burden and does a good job: it discloses that the tool calls the connected client's model via MCP sampling, that it only generates suggestions rather than posting, and that output is style-aware. It doesn't explicitly mention whether user approval is required during sampling or that no data is saved, but the wording is not misleading.

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 a single, tightly worded sentence. It front-loads the primary action and output, then adds the method and grounding in a natural second clause, with 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 simple two-parameter tool with no output schema, the description covers the core purpose, number of results, method, and style context. It doesn't spell out the exact return format or explicitly confirm that nothing is published, but these are inferable and the sibling tool list reinforces that this is a suggestion-only action.

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

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

Schema description coverage is 100%, so both parameters ('topic' and 'tone') are already fully documented in the input schema. The description adds contextual framing but no parameter-specific details beyond what the schema provides, which matches 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 ('Generate'), a resource ('caption options'), an exact quantity ('3'), and the context ('for a post'). It also names the method (MCP sampling) and grounding signal ('recent caption style'), making it clearly distinct from sibling posting, scheduling, and comment 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 clearly implies when to use this tool—when on-brand caption options are needed for a post—by highlighting the grounding in the account's recent caption style. Since all siblings are posting, scheduling, or comment tools, there is no overlap requiring explicit exclusions; a minor gap is that it doesn't explicitly say 'use before publishing.'

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