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

Annotations already indicate this is a non-read-only, non-destructive, open-world operation. The description adds useful behavioral context by explaining that approval makes the reply publicly visible and that the tool is Threads-specific, though it does not describe permissions, reversibility, or rate limits.

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

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

Two tightly written sentences with no filler. The core action and scope are front-loaded, followed by the key alternative.

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

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

The tool has complete schema coverage, annotations, and an output schema. The description supplies the remaining decision-relevant context: platform scope, public-visibility effect, and the sibling alternative for non-approval.

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 parameter meanings are already fully documented in the input schema. The description does not add syntax, format, or selection detail beyond identifying that the target is a reply waiting for approval.

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: approve a pending Threads reply on one of the profile's posts. It also gives the outcome, making the reply show publicly, and scopes the operation to Threads, so it is clearly distinguishable from related 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?

It explicitly names the alternative for the opposite action: use ignore_comment to leave the reply unpublished. It also clearly limits the tool to Threads, leaving little ambiguity about 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?

Annotations already indicate destructiveHint: true, so the description doesn't need to restate that. It adds minimal context by specifying the identifier. No mention of whether cancellation is reversible or if there are side effects, but with destructiveHint present, a 3 is reasonable.

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 sentence, front-loaded with the action and the key parameter. No fluff, though it could specify the type of job_id (e.g., string) but that's in schema.

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 action with destructive annotationable, the description is adequate. It doesn't explain return values, but output schema exists, so that's covered. Missing when to use and potential error cases, but given simplicity, average.

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 has 1 param with 0% description coverage)Skip. The description states that job_id is used to cancel, which adds the context that jobId is a job identifier, but it's already implicit in the param name. The description adds minimal meaning beyond the 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?

Clearly states it cancels a scheduled post, identified by job_id. The verb 'cancel' and resource 'scheduled post' are specific. Though similar to edit_scheduled, it distinguishes itself by the action of cancellation.

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 on when to use this versus edit_scheduled or retry_post. No mention of prerequisites like needing a valid job_id or that the post must be in scheduled state.

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

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

Annotations declare destructiveHint=true and openWorldHint=true, and the description goes well past them: it warns that `edit` does not retain prior text, that `banAuthor` bans the commenter channel-wide, that unsupported combos return 400 `platform_not_supported`, that TikTok actions need the 'comments' capability granted at connection time (with reconnect required), and that nothing is sent until `confirmed: true`.

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?

Front-loads the primary intent and the `platform` selector, and every sentence carries real information. The dense platform-by-platform enumeration and the capability paragraph make it long and somewhat run-on for a description that must be parsed quickly, but there is little wasted 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 an 8-parameter, 5-platform polymorphic mutation tool with an output schema, the description covers the aspects the schema cannot: platform/action compatibility, capability prerequisites, error behavior, irreversibility of edit and banAuthor, and the two-step confirmation protocol. Nothing an agent needs to invoke it safely 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 baseline would be 3, but the description adds conditional semantics the schema only partially captures — postId applicability per platform/action, `message` being Facebook-edit-only, `banAuthor` valid only with YouTube hide, and commentId being unnecessary for Instagram enable_comments/disable_comments.

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?

Opens with a specific verb+resource ('Moderate or react to a comment on one of the profile's own posts') and explicitly frames this as one polymorphic endpoint selected by `platform`. It distinguishes itself from the sibling per-action tools (hide_comment, like_comment, pin_comment) and from delete_comment by naming that tool as a different operation.

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 per-platform matrix of supported actions (TikTok hide/like/pin, Facebook edit, Instagram enable_comments, YouTube hold, Threads approve/ignore) and states the failure mode when an action isn't supported. It also spells out the decision procedure for the approval flow: call without `confirmed` first to preview, then repeat with `confirmed: true` after user approval.

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 mutation profile (readOnlyHint=false, destructiveHint=false). The description adds useful behavioral context beyond those annotations: the hard dependency on the preceding PUT request, the fact that it will fail or produce unusable media without that step, and the temporary nature of the returned URL. This is meaningful situational transparency.

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

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

The description is three short, front-loaded sentences: step identity, call precondition, and output usage. There is no filler or redundancy, and the complexity is low. It uses a compact, informative structure rather than burying details; a 5 may be one sentence too lean, but this is already efficient.

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 with an output schema, the description covers the essential context: the step position, the required precondition, failure scenario, return value, and downstream consumers. It does not detail timeouts, retries, or auth, but those are likely shared across the API and not necessary 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?

Schema coverage is 100% and uploadId is well-documented as 'upload_id returned by create_media_upload.' The description adds additional semantic constraint not visible in the schema: the uploadId must correspond to an upload whose bytes were actually PUT to the upload_url. This helps the agent reason about valid values beyond the schema's type and origin.

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 explicitly states the tool's role as 'Step 2 of staging a local file' and describes the return value ('temporary media_url'). It distinguishes itself from sibling tools like create_media_upload (step 1) and upload_video/upload_photos/upload_document by positioning the result as the input to those upload tools, giving it a specific verb-resource pairing.

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 conditional: 'Call it only after the file bytes were actually PUT...' and states the failure consequence if that precondition isn't met ('fails or yields no publishable media'). It also provides the downstream usage by naming the three upload tools to pass the returned media_url to, making the intended workflow 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?

Despite annotations already declaring destructiveHint and openWorldHint, the description adds substantial non-obvious behavior: X daily write limits with exact thresholds, 429 x_daily_write_limit plus retry_after, the 400 x_links_not_allowed refusal, link stripping surfaced in warnings, and TikTok capability-gating that requires reconnection. This is exactly the operational context annotations cannot 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?

Front-loaded with the core action and the exactly-one-of constraint, then layered platform notes and the safety protocol. Every clause carries real information, though the single dense paragraph makes the platform-specific rules harder to scan than a short bulleted structure would.

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

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

An output schema exists, so return values need not be explained, and the description still calls out that preflight responses list stripped links in warnings. Combined with auth/capability requirements, error codes, and the two-step confirmation flow, an agent has everything needed to invoke this destructive, open-world 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%, so the baseline is 3, but the description earns above baseline by explaining platform-specific parameter interplay the schema only states per-field: 'TikTok always needs postId; add commentId on top of it to reply', and the mutual exclusivity of the three target parameters. It does not document the platform default or the user parameter's role, which keeps it from a 5.

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?

Opens with a specific verb and resource ('Post a top-level comment or a reply on a post') and immediately distinguishes the two modes via the exactly-one-of rule over commentId/postId/postUrl. An agent knows what the tool does and which shape of call it is making before reading the schema.

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

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

Gives explicit per-platform conditions (Instagram replies-only, TikTok needs postId plus optional commentId, X link restrictions) and a clear when-to-call protocol via the confirmed approval loop. The gap is sibling differentiation: reply_to_comment, public_reply_to_comment, and reply_to_google_business_review exist in the same family and the description never says why to pick this one 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?

Annotations are minimal, so the description carries the burden. It discloses the short-lived upload_url, the requirement to PUT raw bytes with matching Content-Type and size, the 24-hour staging deletion, and the safety of scheduled posts via upload_video copying to durable storage. No contradiction with readOnly/destructive 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?

Three dense sentences with no filler: purpose first, then return value and required workflow, then when not to use, then lifecycle/durability. 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?

Covers return values, next steps, constraints, TTL, and exception path. Given the output schema fills in exact response shape, nothing critical is missing for an agent deciding to call this tool.

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

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

Schema already documents filename, contentType, and contentLength well, so the baseline is 3. The description adds meaningful behavioral context by requiring that the subsequent PUT uses the same Content-Type and size declared in these parameters, which is valuable beyond the schema.

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

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

Clearly identifies itself as 'Step 1 of staging a local file for publishing', states what it returns (upload_id, short-lived upload_url), and distinguishes itself from complete_media_upload and upload_video. An agent can immediately understand its role in the workflow.

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

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

Explicitly states when it is useful (client can perform HTTP PUT), when it is not (model cannot read chat attachments or /mnt/data paths), and gives concrete alternatives (ask for a public HTTPS URL or send to app.upload-post.com). Also names the required follow-up call.

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

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

Annotations declare readOnlyHint false and destructiveHint false, which align with the description's 'Create' action. The description adds context that the profile is a logical container for connected socials, providing some behavioral clarity beyond the annotations. However, it does not disclose side effects, permissions required, or whether the operation is reversible, but given the annotations already cover the safety profile, the bar is lower and a 3 is appropriate.

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

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

The description is a single, well-structured sentence that immediately conveys the core purpose without any fluff. It front-loads the action and resource, and the clarifying parenthetical adds value without redundancy. Every word earns its place, making it exceptionally concise and clear.

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

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

Given the tool's low complexity (only one parameter) and the presence of an output schema (which presumably documents the return value), the description covers the essential concept of what a profile is. It explains that it is a logical container, which is helpful for an agent to understand the abstraction. However, it leaves out details like whether username has any validation rules or if there are any side effects on connected socials, but these are minor for such a simple operation.

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

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

The schema description coverage is 0%, and the description does not mention the 'username' parameter at all. While the parameter is simple (a string), the description provides no additional meaning, such as format, uniqueness constraints, or any examples. Since the schema itself only gives the type and required status, the description fails to compensate for the lack of coverage, resulting in minimal semantic enrichment.

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 ('Create a new Upload-Post profile') and specifies the resource type. It distinguishes itself from sibling tools by naming a specific concept (logical container for connected socials), which is unique among the listed siblings. However, it could elaborate a bit more on what 'profile' entails beyond the container metaphor, so it does not reach 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 no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites, exclusions, or conditions. While the name 'create_user' implies a clear use case, there is no explicit context about when not to use it or how it fits with related tools like 'list_users' or 'delete_user'. The description assumes the agent will infer usage from the name alone.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's job is to add specificity — and it does, by naming what is destroyed (the monitor plus its stats and logs) and stating irreversibility. It does not cover auth requirements or any cascade beyond stats/logs, keeping it short of a 5.

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

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

Two sentences, both front-loaded with the highest-stakes information (permanence and destruction scope) first. 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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. What's missing is routing guidance toward the reversible siblings for a destructive tool, which matters given how many autodm_* siblings exist.

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?

Only one parameter and schema coverage is 100%, so the schema fully documents monitor_id including its provenance (list_autodms, start_autodm). The description adds nothing about the parameter, which is the expected baseline here.

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?

Specific verb ('Permanently delete') plus resource ('an AutoDM monitor') with scope qualifier ('with its stats and logs'). It's clearly distinct from sibling management tools like pause_autodm or stop_autodm, though it never explicitly contrasts itself with them.

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

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

The 'Permanently... Cannot be undone' framing implies caution and thus when to prefer a non-destructive alternative, but no alternative is named. An agent must infer that stop_autodm or pause_autodm exist for reversible cases.

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, readOnlyHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-structured context: the TikTok capability prerequisite, that it is granted at connection time, and the reconnect remedy — a real operational constraint. It does not state irreversibility or failure behavior, keeping it below 5.

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

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

Three tight sentences, front-loaded with the core action and ID, then platform deltas, then the capability prerequisite. The final sentence is long but each clause carries actionable information; 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?

An output schema exists, so return values need no explanation. Combined with annotations and full schema coverage, the description supplies the missing prerequisites and per-platform parameter rules. It is slightly incomplete on whether platforms other than LinkedIn/TikTok (e.g. the instagram default) actually support deletion.

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 baseline is 3. The description adds relational value the schema does not: postId is listed as optional in the schema yet the description states LinkedIn *requires* it, and it clarifies that TikTok needs only commentId — resolving a per-platform requirement ambiguity.

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 comment by `commentId`') immediately, and the platform-specific detail makes it distinguishable from siblings such as create_comment, reply_to_comment, and the ambiguous comment_action. An agent can identify this as the destructive comment-removal tool without opening the schema.

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

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

Gives clear conditional guidance: LinkedIn additionally requires postId, TikTok needs only commentId, and TikTok requires the 'comments' capability granted at connection time (reconnect if connected earlier). What is missing is explicit routing against alternatives like comment_action or public_reply_to_comment, 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?

Beyond the destructiveHint annotation, the description explains that deletion is permanent, disconnects socials, requires user approval via confirm_username, and returns a preview of what would be deleted when confirmation is absent. This adds substantial behavioral context for a destructive operation.

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

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

The description is compact and front-loaded, starting with the permanent deletion effect and then the confirmation requirement. Every sentence adds safety-relevant information 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 destructive tool with annotations and an output schema, the description covers the key missing context: permanence, social disconnection, confirmation behavior, and the no-confirm preview response. No critical invocation detail appears absent.

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 confirm_username, and the description reinforces its safety role: it must repeat the profile name and otherwise nothing is deleted. The username parameter is only indirectly described as the profile name, which is adequate but not fully detailed.

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: permanently delete a profile and disconnect its socials. This clearly separates it from siblings like create_user and list_users by operation type, though it does not explicitly name alternatives.

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 important usage condition: deletion only occurs when confirm_username repeats the profile name and the user approves. However, it does not explicitly compare this tool with alternatives such as list_users or create_user, so guidance is implied rather than complete.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds substantial context beyond them: `media_url` is signed, needs no API key, expires 24 h after job completion, while `download_url` requires the user's Upload-Post API key. Those auth, expiry, and credential nuances are exactly the behavioral details an agent cannot get from 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 purpose, then the two return fields and their constraints. Every clause carries information (temporary, signed, no API key, 24 h expiry, downstream usage) and nothing is 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?

Although an output schema exists, the description still usefully characterizes the two returned URL fields and their caveats, plus the auth requirements for each. Combined with the read-only annotations and the downstream upload guidance, an agent has everything needed to call this 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?

Only one parameter (`jobId`) exists and the schema has 0% description coverage, so the description must carry the burden. It implies the job must already be finished (a meaningful precondition) but never explains what `jobId` is or where it comes from (e.g., the id returned by submit_ffmpeg_job), leaving that to inference.

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 returns download instructions/URLs for a finished FFmpeg job's output, explicitly contrasted with streaming output through MCP. This distinguishes it in practice from get_ffmpeg_job/get_job_status, though it never names those siblings directly, so the differentiation is inferred rather than stated.

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

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

It gives clear context for use (a job has finished and you want the output without streaming it through MCP) and even names the downstream consumers: pass `media_url` straight to upload_video / upload_photos. It does not explicitly state when to prefer get_ffmpeg_job or what to do if the job is not yet finished, so no exclusion rules are provided.

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

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

Annotations already flag destructiveHint=true, but the description adds the critical detail that the previous text is not kept and that calling without `confirmed` returns a preview with nothing sent. That preview-then-confirm workflow is exactly the kind of behavioral context an agent cannot 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?

Four compact sentences, each carrying distinct information: scope, destructive effect, and the two-step call protocol. The approval flow is front-loaded as the key operational 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?

With an output schema present and all four parameters documented in the schema, the description covers everything an agent needs: platform restriction, ownership restriction, irreversibility, and the mandatory approval sequence.

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

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

Schema coverage is 100% and the schema's `confirmed` description already explains the preview/approval semantics. The description reinforces the workflow but adds no parameter details beyond what the structured 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?

States a specific verb ('Replace the text of'), the exact resource ('a comment the Page itself wrote'), and the platform scope ('Facebook only'). This clearly distinguishes it from sibling tools like reply_to_comment and create_comment without needing to open either schema.

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

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

Gives strong scoping conditions: only the Page's own comments and only on Facebook, plus a mandatory approval workflow. It stops short of explicitly naming alternatives (e.g., use reply_to_comment for other users' comments), so a 4 rather than a 5.

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

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

Annotations only declare destructiveHint=true and readOnlyHint=false, so the description carries real weight here: it discloses that the job ID and media survive, that only pending posts are editable, that unlisted platforms keep their text, and that youtubePublishAt applies only to private videos and is cleared with null. It does not say what error or state change occurs when editing an already-published or in-flight job, which matters for a destructive mutation.

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?

Front-loaded with the operation and its key invariant, then the parameter branches in a logical order; nearly every clause carries information. The single-paragraph, clause-chained formatting makes it denser than it needs to be, and the inline JSON example, while useful, crowds the sentence flow.

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

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

With an output schema present, the description rightly skips return values, and it covers the nested platformContent object and the multi-purpose scheduling fields thoroughly for a 7-parameter mutation. The remaining gap is the failure mode when the target post is not pending, which an agent would want before invoking a destructive edit.

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 already 86%, so the baseline is 3; the description earns above that by explaining the scope semantics of title/caption (all platforms) versus platformContent (only listed keys, with a concrete JSON example), and by characterizing youtubePublishAt as native YouTube scheduling that sets or clears the value. It adds little about jobId, timezone, or scheduledDate beyond what the schema already documents.

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 ("Edit a pending scheduled post in place") and adds the distinguishing constraint that the job ID and media are preserved, which separates it from a delete-and-recreate flow. It stops short of naming the sibling tools (list_scheduled, cancel_scheduled, retry_post) it might be confused with, so an agent still has to infer the boundary from names alone.

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

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

It clearly states the two mutually exclusive edit paths with the condition that selects each: title/caption rewrite every platform, while platformContent targets only listed platforms. It also sets an explicit exclusion ("First comments cannot be edited on a pending post"), but gives no guidance about published vs pending posts or when to prefer unpublish_post/retry_post over editing.

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 destructiveHint=true, and the description explains exactly why: "Each call resets the profile's connection-page settings to the values passed," which is genuinely additive information an agent would otherwise have to discover by breaking a profile. It does not state JWT lifetime, scope of the token, or which settings are cleared when a param is omitted, which are the remaining behavior gaps.

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

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

Four short sentences, each doing distinct work: purpose, prerequisite, destructive side effect, alternative. The alternative is placed last where a routing rule belongs, and nothing is repeated from the schema or annotations verbatim.

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 output schema covers return values, so the JWT/URL needn't be explained. However, for an 11-parameter destructive tool at 18% schema coverage, the definition leaves material gaps: which settings get reset when a field is omitted, and how long the JWT is valid / who may use it, are both unanswered.

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 18% across 11 parameters, so the description carries the burden — but it names none of the nine undocumented parameters (logoImage, platforms, redirectUrl, connectTitle, showCalendar, readonlyCalendar, connectDescription, redirectButtonText, username). It only implies collectively that they are connection-page settings, which helps framing but not per-parameter meaning.

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 dual resource — "Generate a JWT + connection URL" — and pins the audience and scenario (end-user connecting socials inside an embedded, white-label Upload-Post flow). This is clearly distinguishable from the adjacent get_connect_link and validate_jwt siblings without opening any schema.

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

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

Gives an explicit prerequisite ("The profile must already exist") and an explicit routing rule to an alternative tool ("To simply help the account owner connect their own socials, prefer get_connect_link"). An agent has both the when and the when-instead handed to 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, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the useful framing that results are scoped to the currently connected account (an auth dependency), but says nothing about failure behavior when the connection is invalid. A 3 is appropriate given the lower bar set by annotations.

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

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

Two short sentences, zero waste, and the substance (what is returned) is front-loaded ahead of the usage hint.

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 documenting return values and annotations covering safety, plus no parameters, the description covers nearly everything needed. The only minor omission is what happens when the connection is not authenticated, which would matter for the 'confirm the connection works' use case.

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

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

The tool takes zero parameters, so per the baseline this is a 4. There is no parameter semantics for the description to add.

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 ('Return the connected Upload-Post account') and enumerates the fields returned (email, plan, usage limits). It is clearly account-level and distinguishable by implication from siblings like get_platform_metrics and list_users, though it never names those alternatives 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?

Gives a concrete usage recommendation: 'Useful as a first call to confirm the connection works before doing real work.' That is a clear when-to-use signal, but it offers no when-not-to-use or named alternative for account details.

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

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

Annotations already declare read_only_hint=true and destructive_hint=false, so the description need not restate that. The description adds valuable behavioral context by disclosing that Instagram returns two audience breakdowns with a specific shape (`follower_demographics` and `engaged_audience_demographics`), which is not evident from annotations or schema. This goes beyond the read-only hint to explain a platform-specific output variation. No contradiction with annotations.

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

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

The description is a single, well-structured sentence that front-loads the core purpose and tacks on a relevant platform-specific note. There is no redundant wording or filler. It is concise while still conveying important contextual detail.

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

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

With an output schema present, the description need not detail return values. It covers the main behavior and the notable Instagram-specific breakdown, which is the only non-obvious output detail. The schema covers parameter constraints (e.g., LinkedIn pages must be administered), so the description is sufficiently complete for an agent to 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?

Schema description coverage is 50%, with pageId and pageUrn having descriptions but profileUsername and platforms lacking them. The description indirectly explains platforms as 'selected platforms' and mentions Instagram-specific output, but it does not add syntax or meaning for profileUsername or clarify the platforms array beyond what the enum already provides. It partially compensates for the coverage gap but not fully.

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 provides aggregated analytics for a profile across selected platforms, listing specific metrics (followers, views, engagement). It distinguishes from sibling tools like get_post_analytics (post-level) and get_platform_metrics (platform-level) by explicitly targeting profiles. The verb and resource are unambiguous.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention that for post-level analytics one should use get_post_analytics, or that get_cached_post_analytics might be more efficient. The phrasing 'across selected platforms' implies filtering but provides no usage 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?

Annotations already mark the tool as read-only (readOnlyHint=true) and non-destructive (destructiveHint=false), so the description does not need to repeat that. It goes well beyond annotations by disclosing the server-side window clamping ('at most 60 days, always ending before today – a wider range is trimmed, not rejected'), the benchmark behavior (always returns the 25 accepted values, and adds a benchmark object when a category is set), and the capability requirement. These are significant behavioral details that an agent would not know otherwise, making the tool's runtime behavior fully transparent.

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 relatively long but every sentence carries information. It is front-loaded with the core purpose, followed by return fields and specific behavioral notes. The structure is logical and avoids redundancy. It could be slightly more concise (e.g., the capability note could be trimmed), but it is not verbose or repetitive. The density of useful facts justifies a 4, as it is more than minimal but still efficient.

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 that the tool has an output schema (so return value details are covered elsewhere), the description covers all critical aspects an agent needs: the purpose, the response structure (list of keys), the benchmark behavior, the clamping behavior, and the prerequisite capability. It even explains how to discover valid benchmark categories (omit the parameter). There are no missing pieces that would prevent a correct invocation or interpretation. 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%, so the baseline for this dimension is 3. The description adds meaningful semantics beyond the schema: for benchmark_category it explains 'Must be one of the benchmark_categories the response lists; omit it on the first call to read them,' which is crucial usage guidance not present in the schema. It also clarifies endDate clamping and that platform values are constrained to an enum (though schema already lists that). The additional explanation of the interplay between benchmark_category and the response's benchmark_categories adds real value, so a 4 is warranted.

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 begins with a precise, specific statement of what the tool does: 'Who follows the profile, when they are online and what they tap on it.' It clearly identifies the resource (profile audience) and the action (retrieving insights). It also notes it's a single endpoint for every network selected via 'platform', which distinguishes it from generic analytics tools. The level of detail about return fields (audience.countries, activity_by_hour, etc.) leaves no ambiguity about the tool's purpose.

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

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

The description gives clear context on when to use the tool—when you need audience composition, activity patterns, or benchmark comparisons. It also provides a critical prerequisite: 'Requires the 'profile_analytics' capability on the profile's TikTok account,' which is a form of usage constraint. However, it does not explicitly name alternative tools or state 'use X instead when you need Y,' leaving some inference to the agent. It is still clear and actionable, so a 4 is appropriate.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds which events appear in the log (comments seen, DMs sent or failed), but says nothing about pagination, time ranges, or retention, and an output schema already exists to describe the return shape.

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

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

A single front-loaded sentence with the resource scope first and the log contents second; there is no filler or redundancy.

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

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

For a one-parameter read tool with annotations and an output schema, this covers what an agent needs to select and call it correctly. Missing only minor operational details like time-range or pagination behavior.

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

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

Schema coverage is 100% and the monitor_id property already documents its provenance ('from list_autodms or start_autodm'). The description adds no format or semantic detail about the parameter beyond what the schema provides, so baseline 3 applies.

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

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

The description states a specific verb ('Read') and resource ('activity log of one AutoDM monitor') and even names the log contents (comments seen, DMs sent/failed). It is clear what the tool does, though it does not explicitly distinguish itself from a sibling like get_history.

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?

Scoping to 'one AutoDM monitor' implies the monitor_id requirement and that list_autodms/start_autodm supply that ID, but no explicit when-to-use or when-not-to-use guidance is given against alternatives such as get_history.

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 readOnly annotation, it discloses important behaviors: no background refresh, `captured_at` reflects the last live read, posts not previously fetched are absent, and the tool is exempt from the live rate limit. It also documents pagination behavior (`next_cursor`/`has_more`) in the description, which is not visible in the schema 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?

Three sentences carry the full load: purpose, cache freshness, rate-limit advantage, and pagination. Every clause earns its place — no filler or schema duplication. The purpose is front-loaded, and the comparison to the sibling comes early enough for fast decision-making.

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 output schema exists and the parameter schema covers everything, the main risks for an agent are misunderstanding that this is cached and lacks fresh data, and not knowing when to avoid it. The description fully addresses these, and also provides the pagination loop, the absence of refresh, and the `captured_at` meaning. No critical behavior remains unexplained.

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 describes all six parameters at 100% coverage, including defaults, max values, formats, and enums. The description adds semantic value beyond the schema by using the `cursor` contract (`next_cursor` from response back as `cursor` until `has_more` is false), which directly clarifies how the pagination parameter should be used in practice.

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-reource pair: 'Replays per-post metrics Upload-Post already fetched' and immediately distinguishes the tool from the live `get_post_analytics` by noting it does not hit platforms again. It also explains the scope ('ONLY contains posts previously fetched'), so an agent can tell precisely what this tool returns and how it differs from siblings without opening the schema.

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

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

It explicitly tells agents when to prefer this tool: 'prefer it when scanning many posts or paging through a profile's history' and names the key difference from `get_post_analytics` — no platform calls and no rate limit. It also warns about the limitation ('a post never queried live will be absent'), which implicitly tells the agent when to choose the live variant 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?

Goes well beyond the annotations: discloses the hidden side effect of creating a 'default' profile when none exists (consistent with readOnlyHint=false), the 48-hour link validity, and the branch where an existing profile yields the dashboard link instead. Rate limits and auth requirements are not covered, keeping it from a 5.

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

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

Four sentences, each doing distinct work: purpose, trigger conditions, branching behavior, and the post-call workflow. The purpose and the user-facing action 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?

An output schema exists, so return values need no elaboration, yet the description still names the `connect_url` field the agent must surface. For a zero-required-parameter, side-effecting tool, nothing an agent needs to call it and act on the result 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%, so both parameters are already documented. The description adds only indirect meaning (that 'profile' refers to an existing profile and platforms examples), so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Get the link the user opens to connect (or reconnect) social accounts') with concrete platform examples. It is clearly distinct from sibling read tools like get_account_info or get_platform_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?

Explicitly names the trigger conditions ('when list_users shows no profile, or the platform is not connected or needs reconnecting') and specifies the follow-up sequence (give connect_url, wait, call list_users to confirm before publishing). Alternatives and when-not are implied by the prerequisites.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile, so the bar is lowered. The description adds the scoping fact that pages are 'connected to a profile' but discloses nothing further — behavior when the optional profile parameter is omitted, pagination, or failure conditions. It does not contradict the annotations, but contributes little beyond them.

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

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

Six words, efficient and front-loaded, but the brevity veers toward under-specification. The single noun phrase carries only the resource and a vague scope; it earns its place but does little informational work beyond the name and title.

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

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

The tool is simple (one optional parameter, no enums) and an output schema exists, so return values need not be explained. The critical gap is the profile parameter: 0% schema coverage and no description of how to supply it, though its optionality means the tool can still be invoked with no arguments. Adequate for tool selection, thin for correct invocation with the parameter.

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 for the undocumented profile parameter. The phrase 'connected to a profile' merely echoes the parameter name and gives no indication of accepted values, format, or how to identify a profile. It adds marginal meaning but leaves the only parameter effectively undocumented.

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

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

The description names a concrete resource (Facebook pages) and a scope ('connected to a profile'), and the resource name clearly distinguishes it from platform siblings like get_linkedin_pages and get_pinterest_boards. However, the description itself is a noun phrase with no explicit verb — 'List' appears only in the title — and 'Facebook pages connected to a profile' borderlines on restating the name.

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

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

There is no guidance on when to use this tool over alternatives. With a large sibling set containing many similar list tools (get_linkedin_pages, get_pinterest_boards, get_google_business_locations), the description provides no conditions, exclusions, or alternative routing. The agent is left to infer usage solely from the resource name.

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

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

Annotations already indicate a read-only, non-destructive operation. The description adds useful semantic context that this is a monthly plan-allowance comparison rather than a per-job status lookup. For a simple quota getter, this is sufficient transparency.

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

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

Single sentence, front-loaded with the key concept 'monthly FFmpeg processing minutes used vs. plan allowance'. No fluff, no repetition of the tool name.

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 quota tool, the description plus readOnlyHint and an output schema is largely complete. It clearly identifies the metric and comparison. It does not explicitly state when to prefer this over get_ffmpeg_job, but the quota-vs-job distinction is strongly implied by the wording.

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 accepts zero parameters, so no parameter explanation is needed. The description adds meaning to what the tool reports (monthly usage vs. allowance), fully covering the no-parameter case.

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 read-only purpose: report monthly FFmpeg processing minutes used versus the plan allowance. It is unambiguous and distinct from sibling tools like get_ffmpeg_job, which concerns individual jobs, not consumption.

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 explicit guidance is given about when to use this tool versus alternatives such as get_ffmpeg_job or submit_ffmpeg_job. The context is clear from the description, but the description does not help an agent choose between related tools or rule out alternatives.

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

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

Annotations already declare the safe read-only, closed-world, non-destructive profile, so the description's added value is the polling lifecycle: a status field with a terminal 'finished' value and the follow-up call that unlocks the result. It omits other possible states (failed/timeout) and any polling cadence or rate-limit guidance, which keeps it from a 5.

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

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

Two sentences, no filler, with the poll action front-loaded and the follow-up instruction second. Every clause carries information the agent needs.

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

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

An output schema exists, so return values need not be spelled out, and the description sensibly concentrates on the polling lifecycle and the hand-off. The remaining gap is behavioral: non-terminal/failure states and re-poll cadence are unaddressed for what is inherently a repeated-call tool.

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

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

Schema description coverage is 0%, so the single parameter jobId is undocumented in both places. The description refers only to 'an FFmpeg job' and never states that jobId is the identifier returned by submit_ffmpeg_job or what format it takes; the agent must infer the link from the workflow sentence.

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 ('Poll the status of an FFmpeg job'), which cleanly separates it from submit_ffmpeg_job and download_ffmpeg_result in the sibling list. It does not explicitly differentiate itself from the adjacent generic pollers get_status / get_job_status, leaving a small ambiguity about which status tool to reach for.

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

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

Gives a concrete conditional next step: when status is 'finished', call download_ffmpeg_result, and explains why (to get a publishable media_url). That is genuinely useful workflow context. It stops short of naming when to use this versus get_job_status, or how frequently to re-poll, so there are no explicit 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 declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds one useful behavioral detail: only postable locations are returned. It does not describe behavior when profile is omitted or responses are empty, but the annotation coverage lowers the burden.

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

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

One short front-loaded sentence with no redundancy. Every word contributes to the tool's purpose and scope.

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 simple one-parameter tool, available output schema, and strong annotations, the description is reasonably sufficient. However, the parameter semantics and usage guidance are thin enough that an agent might not know how to populate 'profile' or when to prefer this tool over sibling list tools.

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

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

Schema description coverage is 0%, so the description must compensate for the single 'profile' parameter. It weakly clarifies the parameter by referring to 'the profile can post to,' but it does not explain how it should be specified, whether it is required, or what values it accepts.

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 identifies the resource (Google Business Profile locations) and scopes it to 'the profile can post to,' which makes it distinct from sibling get_google_business_reviews. Although the description is a noun phrase rather than a verb phrase, the title supplies the action 'List.'

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

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

There is no explicit guidance on when to use this tool versus alternatives, nor any exclusion such as 'for reviews, use get_google_business_reviews.' The phrase 'can post to' implies use in a posting workflow, but the agent is left to infer the 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?

Annotations already mark it read-only and non-destructive. The description adds one useful behavioral detail: location_id defaults to the account’s selected location. It does not mention pagination, result scope, or any rate-limit/auth implications.

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

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

Two short sentences, front-loaded with the core action, and 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?

With an output schema and read-only annotations present, the description covers the core invocation, required owner, and default location behavior. Minor gap: no explicit pagination guidance, but this is partially inferable from the parameters.

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 decent; the description adds meaning by clarifying that the profile passed must be the owner of the connected account and that omitting location defaults to the selected location. It does not fully explain pageToken or pagination behavior.

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?

‘List reviews for a Google Business Profile location’ states the action, resource, and scope in one sentence)Skip; the title reinforces it and distinguishes it from reply/update 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 implies when to use this tool and gives setup context (‘pass the profile that owns the connected Google Business account’), but it does not explicitly contrast alternatives or state the condition for choosing this over another read 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds that results are paginated and span all profiles, but it does not disclose ordering, inclusion criteria for upload types, or other behavioral details 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?

It is a single front-loaded sentence with no unnecessary words. The scope and pagination behavior are stated immediately.

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 an output schema, the description covers the essential scope and pagination nature. The main remaining gap is that 'uploads' is not further qualified, but the output schema can carry return-value 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 coverage is only 50%, and the page parameter has no schema description. The description says 'paginated' but does not explain page numbering, defaults, or how paging behaves; the limit parameter is already well documented in the schema.

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

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

The description states a specific resource and action: a paginated history of uploads. The scope phrase 'across all profiles' distinguishes it from profile-specific retrieval, though it does not explicitly name sibling alternatives such as get_media.

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

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

The tool's intended use is implied by 'history of uploads,' but there is no explicit guidance on when to use it versus related tools like get_media, get_post_analytics, or get_media_upload. It lacks when-not conditions or named alternatives.

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

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

The readOnlyHint and destructiveHint annotations already convey safety, and the description adds meaningful context by scoping the tool to scheduled/queued upload status checks. It clarifies the input’s origin (posts created via `addToQueue` or `scheduledDate`), which exceeds what annotations alone indicate.

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

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

Two sentences, no filler, with the primary purpose front-loaded. Every word contributes to clarifying what the tool does and when to use it.

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 lookup with an output schema, the description provides necessary context about the resource type (scheduled/queued uploads) and the relevant posting flows. It is slightly incomplete in not mentioning how a jobId is obtained from related tools like `addToQueue` or `list_scheduled`, but not enough to hinder 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?

With schema_description_coverage at 0%, the description must compensate, and it only says 'by job_id' which is close to the schema's `jobId` field name. It adds minimal value by tying the ID to scheduled/queued uploads, but it does not explain how to obtain a valid jobId or distinguish it from other job ID formats among siblings. Adequate but not strong.

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 ('Check the status of a scheduled or queued upload by job_id') and immediately distinguishes it from generic status tools by narrowing scope to uploads created with `addToQueue` or `scheduledDate`. An agent can easily tell this apart from siblings like `get_status` and `get_ffmpeg_job`.

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

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

Provides clear usage context by explicitly stating 'Use this for posts created with addToQueue or scheduledDate'. This tells the agent when to choose this tool, though it doesn't name alternatives or exclude other status tools such as `get_status` or `list_scheduled`.

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, so the safety profile is covered. The description adds the useful scoping detail that only pages connected to a profile are returned, but it does not disclose auth needs, pagination, or rate limits; that is acceptable 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?

The description is a single front-loaded phrase with no filler, and every word contributes meaning. The title supplies the verb, making the combined definition economical and 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?

For a read-only, one-parameter list tool with an output schema and annotations, the description is largely complete: it gives the resource, scope, and profile relationship. Missing details such as the exact profile identifier format and alternative routing are minor for basic 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 0%, so the description must carry weight; 'connected to a profile' clarifies that the profile parameter identifies whose pages are listed. It does not specify the expected format of the profile value, though the schema's required array already signals that the parameter is optional.

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's verb 'List' combines with the description's resource 'LinkedIn company pages' and scope 'connected to a profile' to state exactly what the tool does. The focus on LinkedIn clearly distinguishes it from sibling tools like get_facebook_pages and get_google_business_locations.

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 the use case—retrieving LinkedIn pages for a given profile—but provides no explicit when-to-use guidance, no exclusions, and no mention of alternatives. The agent must infer usage from the resource name and scope.

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, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by documenting the pagination contract (response shape, next_cursor→cursor chaining, terminal page signals). No concurrency, rate-limit, or ordering details are given, so it isn't a 5.

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

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

Front-loaded with purpose, then platforms, then pagination – a sensible order with little waste. The platform enumeration and pagination parenthetical are slightly long but each serves a 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 read-only, paginated list tool with an output schema present, the description covers what to call, what it returns at the pagination level, and how to continue paging. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100% and each parameter already carries rich documentation, including per-platform limit caps and the LinkedIn cursor failure. The description's only added param meaning is the next_cursor→cursor mapping, which the schema states too. 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?

States a specific verb and resource ('Retrieve recent media ... from a profile's connected social accounts') and enumerates the supported platforms. This clearly separates it from sibling write/upload tools (upload_video, create_media_upload) and from get_media_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?

Gives a concrete usage motive ('browsing what already exists on a platform before posting more'), which tells the agent this is an inspect-before-write read. It stops short of naming explicit alternatives or 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 establish read-only and non-destructive behavior, so the bar for extra transparency is lower. The description adds useful context about the upload being short-lived and the URL being a fresh temporary URL, which goes beyond the schema. It still doesn't disclose what happens on expiry or when includeUrl is false, but it provides reasonable behavioral color.

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 with no filler. The key purpose is front-loaded, and the optional URL behavior is stated efficiently. Every clause adds meaning.

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 output schema exists and annotations cover safety, the description supplies the essential behavioral and parameter semantics. It explains the staging context, the short-lived nature, and the optional URL return. It could mention explicit expiration or null-handling behavior, but nothing critical is missing for correct invocation.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It covers uploadId implicitly as the identifier of the upload being queried and includeUrl explicitly via 'Optionally returns a fresh temporary media_url.' The mapping is clear enough for an agent to use both parameters correctly.

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

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

The description states a specific verb and resource: 'Get status for a short-lived MCP media upload.' It further distinguishes this from generic media or status tools by noting it can 'return a fresh temporary media_url for an already-uploaded staging object,' making the resource and behavior unambiguous.

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

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

The phrase 'Internal/app staging helper' gives useful context about intended use, and the short-lived upload description implies this is for checking upload state rather than production media retrieval. However, it does not explicitly mention when to prefer this over siblings like get_media, get_status, or complete_media_upload, nor any usage 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 declare the tool read-only and non-destructive, so the description correctly does not contradict them. It adds scoping context ('available to a profile'), but no behavioral details about authentication, default behavior, or response characteristics. The description carries some value but stays close to what the annotations imply.

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 compact phrase with no filler words, which is front-loaded and to the point. It is adequately concise, though the brief structure leaves out necessary detail that other dimensions penalize.

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 very minimal description and parameter coverage, the overall picture is incomplete: the 'profile' parameter is unexplained, and there is no usage context or link to other tools. Though an output schema exists, the description fails to fill in basic operational context, leaving the agent guessing on how to invoke or select the tool.

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

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

The schema has no property descriptions (0% coverage) and the description only mentions 'a profile' without defining what format it expects (e.g., ID, handle) or how it affects results. This is insufficient for an agent to correctly construct the argument, especially when the parameter is optional but behaviorally meaningful.

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 identifies the resource as Pinterest boards and scopes them to a profile, which is clear and specific. It lacks an explicit verb, relying on the title to infer the 'list' action, but that is a minor omission. Among siblings like get_facebook_pages and get_linkedin_pages, the platform is highlighted, but the description doesn't explicitly distinguish it beyond the resource name.

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 on when to use this tool versus alternatives or what conditions make it appropriate. The description merely states a fact about Pinterest boards without explaining selection criteria, prerequisites, or fallback behavior. The agent is left to infer from the name and sibling 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that it's a reference and includes human labels, but it doesn't disclose any additional behavioral traits such as output format, pagination, or rate limits. Since annotations cover the core safety, the added value is modest.

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, focused sentence that starts with 'Reference:' to immediately signal its purpose. It includes examples and the key detail about human labels, with zero wasted words. The structure is optimal for an agent scanning tool definitions.

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 parameterless reference tool with an output schema present, the description adequately explains what the tool returns (metrics per platform with human labels). It doesn't describe the exact output structure, but the output schema likely covers that. No critical information is missing for an agent to decide 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?

The tool has zero parameters, so the schema coverage is trivially 100% and there is nothing to explain. Per the calibration rule, a zero-parameter tool gets a baseline of 4, and the description correctly adds no unnecessary parameter guidance.

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 returns a reference of available metrics per platform, with examples and human labels. It distinguishes itself from analytics data tools by positioning it as a metadata/reference lookup rather than a data pull, so an agent can tell it apart from siblings like get_analytics or get_total_impressions.

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 an agent needs to know which metrics are available, but it doesn't explicitly state when to use this tool versus alternatives like get_analytics or get_total_impressions. There is no mention of exclusions or when not to use it, leaving the decision partly 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?

Goes well beyond the annotations: it discloses a live platform call with no mutation of post or account, a server-side cached copy, a 5-minute idempotency window, and a per-platform failure mode where post_metrics_error replaces post_metrics while other platforms still answer (citing X's daily live-read limit). That error semantics and rate-limit context is exactly the kind of behavior annotations cannot express. No contradiction with readOnlyHint=false/destructiveHint=false: the tool is non-mutating but does perform external live reads and stores a result copy.

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?

Front-loads the core purpose and keeps everything else in one dense paragraph with no filler sentences. It is on the long side and the TikTok metric enumeration could be trimmed since an output schema exists, but each sentence conveys operational information.

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

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

With an output schema present, the tool does not need to enumerate return fields, yet it still explains the variable post_metrics shape and the error-entry pattern, plus side effects and caching. The only real gap is the missing guidance on where requestId comes from, which matters for a one-parameter tool at 0% schema coverage.

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 0% for the single required parameter, so the description carries the burden and only partially meets it: it names the identifier as `request_id` (note the casing differs from the schema's `requestId`) but never says where to obtain it or what format it takes. The reader knows the parameter identifies the post but not how to source 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?

States a specific verb and resource: per-platform metrics for a specific post identified by request_id. It explicitly distinguishes itself from get_cached_post_analytics by noting it fetches live and that the cached sibling serves later reads of the same post, so an agent can pick between them without opening either schema.

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

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

Names the alternative (get_cached_post_analytics) and the condition that separates them: live fetch now vs. the stored copy. It also warns that repeat calls within 5 minutes return the same result, which tells the agent not to poll. It stops short of an explicit 'use X when / never use Y when' rule, so a 4 rather than 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?

Goes well past the annotations: discloses 60-second caching (2 minutes on X), read-after-write behavior for comments created/deleted through Upload-Post, and a hard TikTok capability gate with a remediation path. These are exactly the operational facts that cause failed calls or stale-data confusion.

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?

Front-loads purpose, then identity rules, then the replies hint, then caching and the TikTok gate — a sensible priority order. The TikTok prerequisite is worth its length, though the platform-syntax parenthetical partially duplicates the schema.

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

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

Covers what the output schema cannot: caching latency, eventual consistency, per-platform ID conventions, the cursor-based pagination entry point, and the one platform-specific authorization gotcha. Nothing essential for a correct first call is missing.

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

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

Schema coverage is 100%, so the baseline is 3. The description restates the postId-per-network mapping and the TikTok no-URL rule, which the schema already documents verbatim in its property descriptions. It adds the unifying frame (one endpoint, choose with `platform`) but no new 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?

States a specific verb+resource ("List comments on a post") and immediately scopes it as a cross-network endpoint parameterized by `platform`. It also pre-empts the most likely confusion by declaring that replies are a parameter of this tool, not a separate 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?

Gives explicit when-to-use guidance for `commentId` (replies vs top-level) and a concrete prerequisite for TikTok (the 'comments' capability, granted at connect time, reconnect required). It does not point to write-side siblings such as reply_to_comment, but for a read tool the selection risk is low.

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

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

Annotations already declare readOnly=true and destructive=false, so the safety profile is covered. The description adds meaning by enumerating returned queue details (slots, time windows, timezone) but does not go beyond that to mention auth needs, defaults, or behavior when profile_username is omitted.

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 that front-loads the resource ('Posting queue configuration') and parenthetically lists key content fields. Every word adds value; there is no fluff.

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

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

With one optional parameter and no explanation of its meaning or effect, plus no mention of what happens when it is omitted, the description leaves an important usage gap. The output schema may cover return fields, but the input behavior is not sufficiently explained for confident 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?

Input schema coverage is 0% and the description does not explain the only parameter, profile_username. Although the name is somewhat self-explanatory, the description adds no information about whether it is required, what it filters, or how it affects the returned settings.

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 'Get queue settings' plus the description 'Posting queue configuration (slots per day, time windows, timezone)' clearly identify the resource and the data returned. It does not explicitly distinguish itself from sibling tools like update_queue_settings or preview_queue, but the getter verb and listed fields make the purpose unambiguous.

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

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

No guidance is given about when to use this tool instead of alternatives such as update_queue_settings or preview_queue, nor are prerequisites or typical invocation contexts mentioned. The description implies it is a read operation, but it does not state exclusions or conditions.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered elsewhere. The description adds genuinely useful operational context (Reddit is unavailable, error_code=reddit_unavailable), but omits behavioral details like pagination, result limits, or what an empty result means.

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 purpose before the caveat. The availability sentence and the publish-target warning overlap slightly but both carry actionable instruction rather than 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?

An output schema exists, so return values needn't be explained, and the read-only profile is covered by annotations. The main residual gap is the undocumented `limit` parameter; otherwise the definition is sufficient to call the tool correctly and to know it currently fails.

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

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

Schema coverage is 50%: `profile` is documented in the schema and echoed in the description, but `limit` (1–200) is unexplained in both schema and description—no default, no pagination semantics. With partial coverage, the description does not fully compensate, keeping this at 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?

States a specific verb and resource ('Recent Reddit posts published from a profile') plus the payload shape (subreddit, flair, score metadata). It does not name any sibling or contrast with alternatives, but no sibling in the list fetches Reddit posts, so differentiation is implicit.

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 when-not ('Do not use reddit as a publish target') but that constraint is about publishing, not about invoking this read tool, and no alternative read tool or fallback is suggested. Usage context for fetching posts is only implied.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read. The description adds the specific polling behavior and the expected terminal states, which goes beyond the annotations. There is no contradiction; it simply adds useful behavioral context about how status evolves.

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, front-loads the purpose, and contains zero fluff. The polling condition is placed second, efficiently guiding usage. 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?

The tool has an output schema that presumably defines the `status` field, so the description does not need to repeat return structure. It gives the essential polling loop and terminal conditions. It does not mention error handling or what to do if the upload never reaches a terminal state, but for a single-parameter read-poll tool this is adequate.

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% (the property has no description), so the tool description must compensate. It mentions `request_id` by name but adds little semantics: it only says 'by `request_id`', implying it is an identifier from an async upload but does not explain its format, origin, or how to obtain it. This is minimal value beyond the raw 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: 'Check the status of an async upload' and identifies the required identifier `request_id`. It clearly distinguishes this from sibling tools like `get_job_status` or `get_media_upload` by focusing on async upload status, though it doesn't name alternatives. The purpose is unambiguous.

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

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

The description provides clear usage guidance: 'Poll this until `status` is "success" or "failed".' This tells the agent exactly when to call it and how to interpret the result iteratively. It does not explicitly mention when to avoid it or alternative tools, but the polling instruction is strong contextual guidance.

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

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

Annotations already declare readOnlyHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: that the output shape depends on `type`, that capability requirements differ by type, and that the platform parameter selects the network. It also implicitly acknowledges the platform_not_supported error via the schema, but that is part of the parameter 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 moderately concise and front-loaded with the core purpose. It contains some redundancy ('One endpoint for both questions' is restated later), but overall it is well-structured and each sentence adds value. Not overly verbose.

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 (6 params, 2 enums, 3 required) and the existence of an output schema, the description covers the essential behaviors: what it returns for each type, capability prerequisites, and how platform selects the network. It does not mention pagination or limits, but the output schema likely covers those. Overall, it is sufficiently complete for an agent to use 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%, so the baseline is 3. The description does add a few nuances (e.g., q should not include '#', and the capability requirement per type), but these are minor and the schema already explains all parameters effectively. It does not fully compensate for any gaps because there are none.

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 provides hashtag or keyword suggestions, explicitly distinguishes between the two output modes, and clarifies that it works across networks via the platform parameter. It avoids vagueness and is easily distinguishable from sibling tools like get_post_analytics.

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 when to use each type ('pick tags that actually have reach for a caption' for hashtags, 'useful for the next video topic' for keywords) and notes capability requirements (profile_analytics and trend_search), with a pointer to list_users. It does not explicitly name alternatives or state when not to use the tool, but the use cases are 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 this a read-only, non-destructive operation. The description adds value by revealing that impressions are aggregated from daily snapshots rather than live data, but it does not disclose limitations like timezone handling, snapshot delay, or how multiple date fields (`date` vs `startDate`/`endDate`) interact.

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 core result is front-loaded, and the second sentence gives the most important parameter semantics without repetition or verbosity.

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 8 parameters, 0% schema description coverage, and a non-obvious set of optional interactions (`date` vs `period` vs `startDate`/`endDate`, plus `metrics`, `breakdown`, `platforms`), the description is too minimal for an agent to reliably choose and fill optional parameters. The output schema covers return values, but input semantics remain under-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 carry parameter meaning. It explains only `period` and `startDate`/`endDate`, leaving the other five parameters (`date`, `metrics`, `breakdown`, `platforms`, `profileUsername`) effectively undocumented in both schema and description. This is a significant gap for an 8-parameter 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?

The description uses a specific verb-resource pairing ('Sum of impressions for a profile') and notes the data source ('daily snapshots'). It is clear, but it does not explicitly differentiate this tool from closely related siblings like get_platform_metrics or get_analytics, 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 gives concrete parameter guidance: use `period` for presets, or `startDate`/`endDate` for custom ranges. However, it does not say when to use this tool instead of the many sibling analytics tools, and it gives no exclusions or prerequisites.

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

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

Annotations only say non-read-only, destructive, open-world. The description adds material context beyond that: the two-step preview/confirm flow where an unconfirmed call sends nothing, the TikTok capability grant at connection time with explicit reconnect remedy, and the per-platform postId requirement. Those are exactly the operational traits an agent cannot infer from 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?

Front-loaded with the core action and its inverse, then platform caveats, then the safety workflow. Dense but every sentence carries necessary information; slight redundancy with the schema on postId and hidden keeps it from 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?

With 7 parameters, three platforms-specific quirks and an output schema present, the description covers the auth/capability story and the confirmation protocol well enough to call safely. The only unexplained surface is banAuthor's side effect (channel ban), which is implied but not described.

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 restates what the schema already documents (hidden: false restores visibility, TikTok/YouTube require postId) and never mentions banAuthor, the YouTube-only author-ban flag, so it adds little beyond structured data.

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 (hide/unhide a comment) plus scope (the profile's own posts) and the exact effect (public no longer sees it, or restored with hidden: false). The multi-platform coverage is enumerated, so an agent can tell at a glance that this is not the same as delete_comment, hold_comment, or approve_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?

Explicitly routes away from the wrong sibling: 'To delete a comment use delete_comment.' It also defines the required invocation sequence for approval (call without confirmed for a preview, then with confirmed: true) and names the platform precondition (TikTok 'comments' capability, reconnect required). That is when-to-use, when-not, and prerequisites in one place.

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

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

The annotations already declare destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds useful behavioral context by explaining that the comment is taken off the public video until approved and can be republished via hide_comment with hidden: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 front-loaded with the core action and state change, followed by the platform restriction and reversal path. Every sentence adds useful information with no 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?

An output schema exists and annotations cover the safety profile, so the description is close to complete. It explains the platform, the public-visibility effect, and how to reverse it, though it omits prerequisites such as required permissions or approval workflow details.

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

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

Schema description coverage is 100%, so the three parameters are already documented in the schema. The description does not add format or syntax details beyond referring to a comment on one of the channel's videos, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: moving a comment to "Held for review" on a YouTube video. It also names the platform and the state change, which distinguishes it from generic comment actions and from hide_comment, whose hidden:false setting is explicitly named for reversal.

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 context: YouTube only, and it names the alternative call for republishing. It does not explicitly explain when to choose hold_comment versus hide_comment, ignore_comment, or approve_comment, so it falls short of full when/when-not guidance.

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

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

Annotations already disclose that this is a non-read-only, open-world, destructive operation. The description adds valuable outcome context: the reply 'stays unpublished', implying it is not deleted but simply left unapproved. It does not discuss reversibility or permissions, but with annotations carrying the safety profile this is a strong addition.

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

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

Two short sentences, front-loaded with the core action and outcome, followed by the platform constraint and alternative. Every sentence earns its place with no waste.

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 presence of an output schema, full parameter documentation, and annotations, the description covers the essential behavioral scope and alternative well. It could optionally clarify the relationship to other comment-state tools, but nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 100% and both parameters (user, commentId) are fully documented there, including the source of commentId. The description adds no additional parameter meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

The description names a specific verb and resource (ignore a reply waiting for approval) and scopes it precisely to Threads posts. It also explicitly distinguishes the tool from the sibling approve_comment, so an agent can identify its function without opening the schema.

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

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

The description clearly states the platform constraint ('Threads only') and points to the alternative tool ('to publish it use approve_comment'). It does not explicitly exclude other comment-management siblings like hold_comment or delete_comment, but the primary usage decision is well covered.

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?

Adds genuinely non-obvious behavior beyond the annotations: the TikTok 'comments' capability requirement, where to verify it (`capabilities` in list_users), and the operational consequence that older connections must reconnect. This is exactly the auth/prerequisite context annotations don't 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, each carrying distinct information (action + inverse, platform scope, prerequisite). The primary action is front-loaded and the caveat follows, with 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?

With an output schema present and full schema coverage, the description needn't explain return values, and the platform/auth constraints are covered. It could note failure behavior for unsupported platforms, but nothing essential for a correct call is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning: the action is performed 'as the profile's account', clarifying the `user` parameter's semantics, and it reinforces the boolean toggle's dual meaning. No syntax or format gaps remain.

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 ('Like a comment as the profile's account') plus the inverse operation via `liked: false`, and scopes it to TikTok and Facebook. It does not differentiate from the ambiguous sibling `comment_action`, which likely overlaps, so an agent can't fully rule out alternatives from the description alone.

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

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

Gives clear conditional guidance: use the default to like, pass `liked: false` to remove the like, and platform is limited to TikTok/Facebook. It also states a prerequisite. It stops short of naming an alternative tool for cases where this one doesn't apply.

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

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

Annotations already declare this is a read-only, non-destructive, closed-world operation. The description adds useful behavioral context by disclosing the default active-only filtering and the fields 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?

Two short sentences with no wasted text. The resource and default filtering behavior are front-loaded, and the parameter exception is stated 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 simple one-parameter list tool with annotations and an output schema, the description is complete. It covers what is listed, the default filter, the override parameter, and the key returned fields.

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 single parameter is fully documented in the schema, establishing a baseline of 3. The description adds value by stating the inverse default (active ones only) and clarifying exactly when include_inactive changes that behavior.

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

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

States a specific verb and resource: list the account's AutoDM and comment auto-reply monitors. It also names the returned fields (platform, state, counters), making it distinguishable from related tools like get_autodm_logs and manage_autodms.

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 defines the default behavior: active monitors only unless include_inactive is true. This gives clear context for when to use the parameter, though it does not explicitly route the agent away from sibling tools such as get_autodm_logs.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety is covered. The description adds only a vague 'recent' ordering hint and profile/platform scoping, without clarifying pagination, auth requirements, or filtering 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?