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

Annotations provide openWorldHint=true and destructiveHint=false, so the bar is lower. The description adds meaningful behavioral context: the action is 'Publish' (visibility implications), it accepts public URLs only, and it supports draft/scheduling behavior. This goes beyond the annotation-provided safety profile. It does not cover auth or irreversibility, but that is not a critical gap given 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, front-loaded with the core action and resource, followed by a concise reference to sibling behavior. Every word earns its place; there is 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 a simple create/publish tool with no output schema and no nested objects, the description plus schema and annotations are sufficient to select and invoke the tool correctly. The only minor gap is that the return shape is not described, but that is optional given the tool's simplicity and the absence of an 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 60%, with 'url' and 'page' and 'publish_at' already described in the schema. The description compensates for undocumented parameters by mentioning 'optional caption' (caption) and 'Same scheduling and draft options as a text post' (draft, publish_at), adding meaning beyond the bare property names.

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 ('Publish'), names the resource ('a photo'), and specifies the source ('from a public URL'). It distinguishes this tool from the sibling 'create_post' by explicitly framing it as a photo post variant and referencing 'a text post' for behavioral comparison.

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 this tool is for publishing photo posts, and the phrase 'Same scheduling and draft options as a text post' provides contextual comparison to the text-post sibling. However, it stops short of explicitly stating when to use this tool versus 'create_post' or other alternatives, so the guidance is inferred rather than explicit.

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 sparse annotations, the description explains the three posting behaviors (immediate, draft, scheduled) and that publishing is the default. It doesn't mention Page-access requirements or external visibility consequences, but the core side effect—creating and publishing a post—is plainly disclosed. 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 short sentences, front-loaded with the core action, then conditional behavior. No filler or repetition of schema text.

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 5-parameter creation tool with no output schema and all parameters documented, the description covers the relevant decision points. It lacks explicit mention of permissions or response semantics, but those are common to this domain and can be inferred from the resource being created.

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

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

With 100% schema coverage the baseline is 3, and the description earns extra credit by explaining the relationship between publish_at and draft ('Leave publish_at empty and draft false to post immediately'). It also clarifies that link is an optional attachment, which aligns with 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 'Publish a text post, optionally with a link,' giving a specific verb, resource, and scope. This clearly distinguishes it from the sibling create_photo_post and from update/delete 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?

It gives clear operational guidance for the main modes: leave publish_at empty and draft false for immediate posting, set draft to keep unpublished, or set publish_at to schedule. It does not explicitly call out alternatives like create_photo_post, but the 'text post' phrase implies the boundary, so the guidance is clear though 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?

Even though destructiveHint already flags danger, the description adds irreversibility ('Cannot be undone'), an access/configuration condition, and a strong recommendation toward hiding. This is decision-relevant context beyond the 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, each carrying distinct value: the operation, the permanence/prerequisite, and the preferred alternative. There is no filler, repetition, or vague phrasing.

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

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

For a two-parameter destructive tool, the description covers irreversibility, gating conditions, and a safer alternative, which is largely sufficient. The main remaining gap is the under-documented comment_id, though the parameter name makes its role broadly 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?

The schema documents 'page' but leaves 'comment_id' with only a type and no description. The tool description does not explain where to find the comment ID, its format, or any additional semantics, so it fails to compensate for the 50% schema coverage gap.

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 target: 'Permanently delete a comment.' The word 'permanently' adds meaningful scope, and the closing guidance about hiding distinguishes this tool from the sibling hide_comment.

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

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

It gives a clear prerequisite ('refused unless deletion is explicitly enabled') and recommends the safer alternative ('Hiding is usually the better answer'). It does not explicitly name hide_comment or spell out when deletion is appropriate, leaving 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?

Annotations already include destructiveHint=true, and the description adds useful behavioral detail: deletion is permanent, cannot be undone, and requires explicit enablement. This goes beyond the structured annotation data and is consistent with it.

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

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

Two short sentences communicate the core action, permanence, and refusal condition with no filler. The most critical information is front-loaded.

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

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

For a two-parameter destructive tool with no output schema, the description covers the operation's nature, consequences, and preconditions. The page parameter is documented in the schema, and post_id is straightforward. Nothing essential is missing for correct invocation.

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

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

Schema description coverage is 50%: page is described, post_id is not. The description does not explain either parameter, but post_id is self-evident and page is already documented in the schema. This is adequate but adds no extra semantic value.

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: 'Permanently delete a post.' This clearly distinguishes it from sibling tools like delete_comment, hide_comment, and update_post without ambiguity.

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

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

The description provides a clear precondition: deletion is refused unless explicitly enabled. It does not explicitly name alternatives, but the post-specific target is clear from the name and description, giving adequate context for when 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?

The annotations declare readOnlyHint=true, and the description is consistent with a read-only operation, so there is no contradiction. The description adds useful detail about the returned fields but does not discuss authentication, rate limits, or default-page behavior; with read-only annotations, 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 a single, front-loaded sentence that succinctly lists the key output fields without filler. It is appropriately sized for a simple tool and every word 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 low-complexity, one-parameter, read-only tool with no output schema, the description is sufficiently complete: it enumerates the returned profile fields, and the schema covers parameter semantics. Nothing essential is missing for an agent to select and invoke 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 schema fully documents the single optional page parameter, including how to specify it by name or id and that omitting it uses the default. Since schema description coverage is 100%, the tool description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description clearly identifies the resource (a Page) and the operation (retrieve profile details), and lists specific fields so an agent knows what information is returned. It does not explicitly distinguish itself from sibling tools like list_pages or get_page_insights, though 'profile details' strongly implies a single-page read.

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 conveys an implied use case: retrieve profile details for a specific Page. However, it offers no explicit when-to-use or when-not-to-use guidance and does not mention alternatives such as list_pages for enumeration or get_page_insights for analytics.

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

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

readOnlyHint=true already covers the safety profile; the description adds that results include impressions, reach, engaged users, and follower change over a date range. It does not disclose pagination or aggregation details, so it adds only moderate 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?

A single, front-loaded sentence conveys resource, scope, and key result fields with no filler. Every word earns its place.

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

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

For a read-only, zero-required-parameter tool, the schema plus annotations cover the inputs and safety profile, while the description covers the result categories. No output schema exists, but the listed metrics give the agent enough expectation of the return value.

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

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

Schema description coverage is 100%, so parameters (page, since, until) already carry their meaning. The description does not add parameter-format or default-value details beyond the schema, justifying the baseline 3.

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

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

The description states a specific verb/resource relationship ('How the Page itself is doing over a date range') and enumerates concrete metrics, distinguishing it from sibling get_post_insights by emphasizing Page-level scope.

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

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

The phrase 'the Page itself' and the date-range framing give clear context for when to query page-level performance. It does not explicitly name alternatives or exclusions, so it stops short of a 5.

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

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

The readOnlyHint annotation already covers the safety profile, so the description does not need to restate that. It adds useful context about the returned metrics and the naming distinction, but it does not disclose behaviors such as time range handling, data availability limits, or whether the response is paginated.

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 first sentence front-loads the tool's core function and return metrics, and the second justifies the separation from page-level analytics. Every word earns its place.

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

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

For a simple read-only insights tool with one required parameter, the description, schema, and annotations cover most of what an agent needs to call it correctly. The only notable gap is the undocumented post_id semantics and the absence of any return-shape details, but the tool's low complexity keeps this from being a serious deficiency.

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 documents the 'page' parameter; 'post_id' has no description, leaving 50% of the parameters undocumented. The description says 'one post' but does not clarify how to identify the post with post_id or how the optional page parameter affects the call, so it does not compensate for the schema coverage gap.

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 'How one post did' and enumerates the exact metrics returned (impressions, reach, clicks, reactions), making the target resource unmistakable. It also explicitly contrasts Post metrics with Page metrics, distinguishing this tool from the sibling get_page_insights without needing to inspect schemas.

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

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

The description explains that Post metrics are named differently from Page metrics and that is why this is a separate tool, giving an implicit directive to use it for post-level rather than page-level analytics. It does not explicitly name the alternative tool or state a direct 'use this when' rule, so it falls just short of full guidance.

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

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

The annotations already indicate non-destructive behavior with destructiveHint=false, and the description adds valuable behavioral details: the action is reversible, and the hidden state still allows visibility to the author and their friends. It goes beyond what annotations alone convey, though it omits details like permission requirements.

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

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

The description is concise, front-loaded with the core behavior, and follows with rationale and a preference comparison. Every sentence serves a purpose without redundancy or filler.

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

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

For a simple three-parameter tool with clear schema descriptions and non-destructive annotations, the description provides the essential context: what the action does, who still sees the comment, that it is reversible, and how it relates to the delete alternative. No critical information 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?

Schema description coverage is 67%, with page and hidden already described in the schema. The description does not add significant parameter-level detail beyond what the schema provides, though the reversibility wording ties into the hidden boolean. This meets the baseline for schema-covered 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 clearly states the action (hide or unhide) and the resource (a comment), and specifies the exact visibility effect: hidden from everyone except the author and their friends. It also distinguishes itself from the sibling delete_comment by explicitly saying 'Prefer this to deleting.'

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 guidance on when to use this tool: it is 'the usual answer for spam or abuse' and should be preferred over deleting. This provides a clear decision rule compared to delete_comment, the main 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 readOnlyHint annotation already communicates that this is a safe, non-mutating operation, so the bar for additional disclosure is lower. The description adds the useful detail that results include author and timestamp, but it does not disclose pagination behavior, ordering, or the effect of the limit parameter.

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. It front-loads the core purpose and follows with a concise usage cue, 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 simple read tool with a readOnlyHint annotation and a schema that documents most parameters, the description covers the essential return contents and use case. It does not describe pagination or output shape beyond author and timestamp, but those are minor gaps 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?

Input schema coverage is 67%, with post_id lacking a schema description. The description only indirectly references post_id via 'on a post' and adds no meaning for page or limit beyond what the schema already states. With partial schema coverage, the description should compensate more than it does.

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 title 'Read comments' and description 'Comments on a post, with who wrote each one and when' clearly identify the resource and the read action. It also distinguishes itself from sibling write tools like reply_to_comment, hide_comment, and delete_comment by framing it as the precursor to replying or moderating.

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 before replying or moderating' gives explicit context for when to call this tool. It does not name specific alternatives or exclusions, but the intended use case is clear enough for an agent to select it over the mutating comment 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 provide readOnlyHint=true, and the description adds useful behavioral context beyond that: the tool lists pages the server can act on and returns id and name. It also frames the call as a prerequisite for later page-scoped operations, which helps the agent reason about workflow. No contradiction with annotations.

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

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

Two short sentences, each earning its place: the first says exactly what the tool returns, and the second gives actionable usage guidance. The most important information is front-loaded.

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

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

For a simple, read-only, parameterless listing tool, the description is complete. It names the output fields, clarifies permission scope, and explains when to call it. No output schema exists, but the description covers the essential return 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?

The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to add about parameter meanings. The baseline of 4 for a parameterless tool 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 ('List') and a clear resource ('every Facebook Page this server can act as'), and explicitly mentions the returned fields (id and name). This distinguishes it from page-scoped tools like get_page and content listers like list_posts or list_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?

It provides explicit timing guidance: 'Call this first when you have more than one, so you can name the right Page on later calls.' This tells the agent when to invoke it and why, though it does not explicitly contrast with get_page for cases where the page id is already known.

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 the description builds on this by disclosing ordering and that reaction, comment, and share counts are included. This adds useful behavioral context 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?

A single compact sentence delivers the core resource, scope, ordering, and return highlights. Every word earns its place and the most important information is front-loaded.

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

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

For a low-complexity, read-only listing tool with no required parameters, the description sufficiently covers what is returned and in what order. Pagination behavior is partially captured by the limit parameter, so 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%, with both page and limit already explained. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

States a clear verb (list), resource (posts on a Page), scope (published only), and ordering (newest first). This differentiates it from siblings like list_scheduled_posts and create_post without needing to open schemas.

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

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

The description clearly implies this tool is for retrieving published post data, not for creating or modifying content. It does not explicitly name alternatives or exclusions, but the 'Published posts' context gives clear situational 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?

The readOnlyHint annotation already covers the safety profile, and the description adds useful scope context (scheduled + drafts, due time per item). It does not disclose ordering, pagination, or how drafts without a scheduled time are treated.

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 efficient sentence that front-loads the key distinction ('not gone out yet') and adds due-time information beyond the title. 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?

Adequate for a simple read-only list tool with one optional parameter, and the due-time mention partially compensates for the missing output schema. Ordering, pagination, and field details are left unspecified.

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 single optional page parameter is fully documented with name-or-id semantics and default behavior. The description adds no parameter detail, which is fine at this coverage level.

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

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

The description states the resource and a crisp inclusion criterion — posts that have not gone out yet, covering both scheduled posts and saved drafts, with their due times. This scope clearly separates it from list_posts, though it doesn't name the sibling explicitly.

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

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

Usage context is only implied: an agent can infer this tool is for viewing pending or unpublished content, but the description never says when to prefer it over list_posts or how it relates to publish_draft. No alternatives or 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?

Annotations already signal openWorldHint=true and destructiveHint=false. The description adds that the tool acts on drafts or scheduled posts and publishes immediately, but it does not disclose whether the draft/scheduled entry is consumed or that the post becomes publicly visible. This is adequate but not detailed.

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 that conveys the action, target, and immediacy without any filler or repetition. Every word earns its place.

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

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

For a simple two-parameter tool with annotations and a fully descriptive schema, this description covers the core purpose and timing. It does not explain return values or post-publication state, but those are not essential for selecting and invoking the tool correctly.

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

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

Schema coverage is 100%, with the schema already describing post_id as 'From list_scheduled_posts' and page as the page name/id with a default. The description adds no additional parameter-level meaning, so the baseline of 3 applies.

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

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

The description states a specific action ('publish') and target resource ('draft or scheduled post') with the key nuance 'immediately.' It is clear and distinguishable from sibling tools like update_post or create_post, though it does not explicitly name a sibling to differentiate from.

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: when you have a draft or scheduled post and want it published immediately. However, it does not explicitly state when not to use it or mention alternatives such as update_post for editing before publication.

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 destructiveHint=false and openWorldHint=true, so the description's job is lighter. It adds behavioral context by specifying the reply is 'public' and posted 'as the Page', but it does not disclose potential side effects, permission requirements, or whether the action can be undone. No contradiction with annotations 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 a single, front-loaded sentence with zero filler. Every word earns its place: the action, object, visibility, and actor are all conveyed 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 three-parameter action tool, the description sufficiently covers what the tool does and who it acts as. It does not describe return values (no output schema) or constraints like comment_id format, but those are minor gaps for this straightforward 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 description coverage is only 33% (only 'page' has a description). The main description hints at the roles of comment_id and message ('reply under a comment') and page ('as the Page'), but it does not provide format, constraints, or default behavior beyond the schema. It partially compensates for low schema coverage but does not fully clarify 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 uses a specific verb ('Post'), a precise resource ('a public reply under a comment'), and the acting identity ('as the Page'). This clearly separates it from sibling tools like hide_comment, delete_comment, and create_post without needing to inspect schemas.

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

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

The action is inherently clear, but the description never states when to choose this tool over alternatives such as hide_comment or delete_comment. It also gives no context about prerequisites or edge cases, so usage is only implied by the tool's name and phrasing.

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

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

The description adds a meaningful side effect beyond the annotations: 'Facebook shows an edit history to viewers.' This tells the agent that edits are permanent in the public record, which complements the non-destructive and open-world annotations. It does not mention auth or rate limits, but it does disclose a key behavioral consequence.

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

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

Two short, front-loaded sentences with no filler. The core action is stated first, and the edit-history note earns its place as essential behavioral context.

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

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

The description is adequate for understanding the basic update operation, and the edit-history note adds context. However, it omits what the tool returns, any permissions required to edit a Page post, and whether only text is editable or other fields are affected. For a mutation tool with no output schema, this is a noticeable gap.

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

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

The description adds no parameter-specific meaning beyond what the input schema already provides. The schema covers message and page, but post_id has no description and the tool description does not fill that gap or clarify constraints, defaults, or formats.

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

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

The description names the exact action and resource: 'Change the text of a published post.' This distinguishes update_post from siblings like create_post, delete_post, and publish_draft, and makes the tool's unique role 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?

No guidance is given about when to use this tool versus alternatives, nor are exclusions or prerequisites stated. Usage is implied by the verb 'Change,' but the description does not actively route the agent away from create_post or publish_draft when appropriate.

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