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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the low-level safety profile is covered. The description adds nothing beyond that: no statement on idempotency (what happens if the account is already on the team), required permissions, or whether the assignment is reversible. For a mutation tool it is thin.

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 short sentence with zero waste and the action front-loaded, but it is under-specified rather than efficient — there was room for a clarifying clause at no cost to brevity.

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

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

A mutation tool with no output schema, no parameter documentation, and annotations that only cover safety hints. An agent cannot tell from this definition what constitutes success or failure (duplicate assignment, invalid team, permission errors), which matters 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% — neither teamId nor accountId is documented in the schema, and the description does not compensate. The names are largely self-explanatory, but there is no statement of expected ID format (opaque ID vs slug) or whether the account must belong to the caller's organization.

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 ('assign') and both resources (account, team), so the action is unambiguous and distinguishable from the sibling remove_team_account. It stops short of explicitly naming that sibling or the team/account relationship, but the core purpose is clear.

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

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

No guidance on when to use this versus remove_team_account, create_team, or update_team, and no preconditions (e.g. account must already be connected, team must exist). The agent must infer usage entirely from the 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds the useful detail of what specifically is validated (key, connectivity, accounts, quota), but says nothing about failure behavior, error surface, or what a failed check looks like — for a diagnostic tool that gap matters.

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, the capability list front-loaded and the action directive last as the actionable takeaway. No filler and nothing repeated from the title.

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

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

There is no output schema, so the description would ideally sketch the shape of the verification result (which checks pass/fail, remediation hints) — it lists the checks but not how results are reported. For a zero-parameter, read-only tool the remainder is otherwise complete.

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

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

The tool takes zero parameters and the input schema is empty with 100% coverage, so there is nothing for the description to disambiguate. Baseline 4 applies for a parameterless tool.

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

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

States a specific verb (verify) and enumerates the exact resources checked: API key, connectivity, connected accounts, and quota. This is clearly distinguishable from siblings like refresh_account, describe_platform, and get_organization, which handle narrower concerns.

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?

"Run this first before any other tool" gives an explicit sequencing directive that an agent can act on directly. It stops short of naming when-not conditions or pointing to alternative diagnostics (e.g., refresh_account for credential refresh), so it falls one step below the top.

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, destructiveHint=false and openWorldHint=true, so the safety profile is partly covered; the description adds the important behavioral fact that this is a human-in-the-loop step producing a URL to be opened externally. It omits whether the URL expires or is single-use, which would have completed the picture.

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 tight sentence, front-loaded with the action and followed by the user-facing consequence. Nothing wasted.

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

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

For a two-parameter tool with no output schema, the description conveys the essential flow but leaves gaps: it never states what the response contains (the URL field), nor what the optional 'client' parameter changes. Adequate but not complete.

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

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

Schema coverage is only 50%: the platform parameter points to describe_platform, but the 'client' enum (web/mobile) has no description anywhere. The description says nothing about either parameter or how 'client' affects the generated URL, so it does not compensate for the coverage gap.

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

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

Specific verb+resource: it builds an OAuth authorize URL for a given platform, and clarifies the result is a URL the user opens rather than a completed connection. That separates it from siblings like refresh_account and disconnect_account, though it doesn't name them 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?

The phrase 'the user opens it in a browser to connect' implies the context of use (initiating a connection flow), but there is no explicit when/when-not guidance and no comparison to refresh_account or check_setup.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) it discloses two behavioral traits that matter operationally: the job is async and must be polled, and it consumes clipping minutes. What happens on job failure or how long processing takes is unstated, so it is not 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?

Three short sentences, front-loaded with the core action, then the async/polling contract, then the cost. Every clause carries distinct information 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?

For an async, quota-consuming creation tool with no output schema, the description supplies the essentials: the async job model, how to poll, and how to check cost. It leaves out return-shape hints (job id for polling) and failure/retry semantics, which an agent would still have to discover.

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 only re-describes channelIds as auto-posting targets and adds nothing on fit, maxClips, or idempotency beyond what the schema descriptions already say.

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 transformation ('cut a long video ... into short vertical clips') plus an optional side effect ('auto-posting them to channelIds'). That is clearly distinguishable from list_clips and get_clip, and the source type (YouTube or public URL) is named.

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

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

Explicitly tells the agent this is asynchronous and to poll get_clip, and points at get_clip_usage for the quota cost — genuine follow-up routing. It stops short of stating preconditions (e.g. that channelIds requires connected accounts) or any when-not-to-use condition.

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 that this is a non-read-only, non-destructive, open-world operation. The description adds meaningful behavior: immediate publishing when scheduledAt is omitted and threading via parentCommentId.

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 main action and followed by the two parameter behaviors that matter. There is no redundant or 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?

The description covers the invocation-relevant behavior for a simple create tool, including scheduling and replies, against annotations that already carry the safety profile. It does not describe the return value or permission requirements, which is a minor gap given the lack of an output schema.

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

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

Schema description coverage is only 40%, so the description must compensate. It usefully explains the ambiguous optional parameters scheduledAt and parentCommentId beyond their schema text, while postId, accountId, and text are straightforward or partially 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 verb and resource: create a comment on a post by the given account. It is clearly distinguishable from siblings such as create_post, update_comment, and reply_to_inbox_item.

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

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

It gives explicit usage conditions for the optional parameters: omit scheduledAt to publish immediately, and pass parentCommentId to reply to another scheduled comment. It does not name alternatives or exclusions, but the create-vs-update distinction is clear.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new behavior: the result is a draft and nothing is scheduled or published, plus a validation dependency on describe_platform. It stops short of describing the return value or partial-failure behavior across multiple accountIds.

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 clauses, zero filler, and the most decision-relevant fact (draft, no scheduling) is front-loaded before the prerequisite. Every sentence earns its place.

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

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

For a seven-parameter creation tool with no output schema, the definition covers the key semantic (draft, nothing published) and the required setup call. It omits what is returned (e.g. post ids) and how multi-account creation behaves on partial failure, which would matter for a batch-capable write.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema. The description only references scheduledAt, which is not even a parameter, and adds no format or syntax guidance for caption, postType, threadParts or accountOverrides. Baseline 3 applies when the schema carries the load.

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 ("Create a post") plus the crucial scope qualifier that it is "saved as a draft — no scheduledAt," which is exactly what separates it from the sibling schedule_post. An agent can pick this over schedule_post without opening either schema.

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

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

Gives an explicit prerequisite ("Call describe_platform first for per-platform required fields") and implies the draft-vs-scheduled split. It does not explicitly name schedule_post as the alternative when a publish time is desired, so routing is clear but not fully spelled out.

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=false, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that this is a bulk CSV import and notes expected columns, but it does not explain import-job behavior, validation, partial failures, or what is 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, front-loaded with the core action and source options. There is no wasted language and the extra column note is directly relevant.

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

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

This is a mutating bulk-import tool with no output schema and an open-world hint. The description covers the basic action but omits important context such as whether the import is asynchronous, how import progress is tracked, and what happens with invalid rows.

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 two parameters are already documented. The description adds useful semantics beyond the schema by naming the expected CSV columns, caption and accountId, although it does not explicitly clarify whether exactly one of csv or url must be supplied.

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: "Bulk-create posts" from CSV text or a public CSV URL. The word "Bulk" and the CSV source distinguish it from the single-post create_post sibling without needing to name it.

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 implies usage for bulk post creation and names two input sources, but it does not explicitly say when to use this instead of create_post, nor does it state prerequisites or when not to use it. Usage is inferable but not fully guided.

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 it is a non-readonly, non-destructive, open-world creation operation, so the safety profile is covered. The description adds only that accounts can be optionally assigned at creation; it says nothing about duplicate-name/slug behavior, side effects on the organization, or error conditions for a mutation tool with openWorldHint=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?

A single front-loaded sentence with no filler. Brevity is not the problem here; the issue is that it is too thin rather than too 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?

A creation/mutation tool with five undocumented parameters, no output schema, and no annotation beyond hints needs more: what fields are auto-generated vs. required, what accountIds expects, and what a successful create returns or how it can fail. The one-line description leaves these gaps open.

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 all five parameters (name, slug, avatarUrl, accountIds, description) are documented only by type/constraints. The description touches only accountIds ('optionally assigning accounts') and leaves slug, avatarUrl, and description entirely unexplained in both schema and description.

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

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

States a specific verb and resource ('Create a team') and is clearly distinct from siblings like list_teams, get_team, update_team, delete_team. It adds only the parenthetical about account assignment, so it's clear but does not differentiate beyond name/sibling naming.

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 vs. alternatives such as add_team_account or update_team, and no prerequisites (e.g., whether the caller must be an org admin). The only implied usage is 'create a new team, optionally with accounts', which is derivable 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 safety profile is covered structurally. The description contributes only the ambiguous 'pending' scope note; it never says whether the deletion is permanent, what happens if the comment is already published, or what error to expect.

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

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

A single front-loaded sentence with no waste, but its brevity comes from under-specification rather than discipline. It leaves out scope and effect details an 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?

For a destructive mutation with no output schema and 0% parameter documentation, the description should cover irreversibility, failure modes, and ID sourcing. None of that is present; only the destructive annotation hints at impact.

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% for the single required parameter, commentId, so the description carries the full burden. It says nothing about the ID format, where the ID comes from (e.g., list_comments/get_comment), or whether the ID must refer to a pending comment.

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 verb+resource ('Delete a ... comment') is specific and distinguishable from siblings like delete_post, delete_media, or update_comment. However, the qualifier 'pending' is left unexplained, so an agent cannot tell whether the tool only works on pending comments or also removes published ones.

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 versus update_comment, list_comments, or other deletion tools, and no preconditions are stated. The only contextual hook is the unexplained 'pending' qualifier.

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 nothing beyond them: no statement that deletion is permanent/irreversible, no mention of what happens to media referenced by scheduled posts, and no confirmation/undo 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?

One short, front-loaded sentence with zero filler, which is the right shape for a destructive single-object delete. It is arguably under-specified rather than padded, so it earns credit for efficiency.

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

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

This is a destructive mutation with no output schema and an undocumented required identifier, yet the description explains neither irreversibility nor how to source the ID. For a delete operation with this much potential for harm, that leaves real gaps.

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

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

The single parameter mediaId has 0% schema description coverage, so the description must carry the burden and it does not. It never says how to obtain a valid mediaId (e.g., from list_media or get_media) or what format it takes.

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 one media item"), and the word "one" implicitly contrasts with the sibling delete_media_many. However, it never names that sibling explicitly, so the differentiation is only inferable.

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 when-to-use guidance, no preconditions, and does not point to delete_media_many or list_media/get_media for identifying the target item. An agent must infer the single-vs-bulk routing entirely from the tool 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 declare destructiveHint=true and openWorldHint=true, so the safety profile is known. The description earns credit for noting per-id outcome reporting, which hints at partial-failure behavior, but it never states atomicity, irreversibility, or any confirm/rate-limit requirements for a destructive batch call.

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

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

A single front-loaded clause with zero padding. It is tight but borders on underspecified for a destructive batch operation.

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 batch tool with no output schema and no annotations gap to fill on safety, the description should disclose batch limits and what a 'per-id outcome' looks like (partial success? errors inline?). It signals the shape of the result but not enough to call it complete.

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

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

Schema coverage is 0% for the single mediaIds parameter, and the description says nothing about it — no format (opaque ID vs URL), no maximum batch size, no note that minItems is 1. The schema carries a bare array type and nothing else.

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 several media items') and adds an outcome clause ('reports per-id outcomes'). 'Several' implicitly distinguishes it from the singular delete_media sibling, though the sibling is never named.

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 word 'several' implies this is the batch path versus delete_media for one item, but there is no explicit when-to-use, no exclusion, and no prerequisite (e.g., whether IDs must exist or whether this cascades to posts referencing the media).

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

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

Annotations already declare destructive=true and readOnly=false, so the safety profile is known. The description adds important scoping behavior beyond the annotations: published posts are preserved, so the deletion is limited to drafts and scheduled posts. It does not discuss reversibility or side effects, but the key behavioral constraint is disclosed.

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 that communicates the action and the important scope exception with no filler. Every phrase earns its place.

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

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

For a simple one-parameter deletion tool whose annotations already cover destructiveness, the description supplies the critical business rule that published posts are not deleted. The remaining gap is postId semantics, which is not covered in either schema or description.

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

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

The schema has 0% description coverage and the description says nothing about the required postId parameter, such as its format or where to obtain it. The parameter name is self-evident, but the description does not compensate for the missing schema documentation.

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

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

The description states a specific verb and resource ('Delete a draft/scheduled post') and immediately distinguishes the target scope from published posts. An agent can tell that this is not a general post-removal tool and that published posts are excluded.

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 establishes the applicable case: draft or scheduled posts can be deleted, while published posts are kept. It does not name an alternative workflow for published posts, but the exclusion is explicit enough to guide use.

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 known. The description adds a genuine behavioral constraint — the team must no longer own accounts — which is context annotations cannot express. However, it never says whether the deletion is irreversible, whether it fails when accounts remain, or what happens to team members.

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

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

A single front-loaded sentence with no filler; the destructive action and its precondition come first. It is nearly as short as it can be, though the terseness leaves the constraints implicit rather than spelled out.

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, irreversible-by-nature operation with no output schema and an undocumented parameter, the description should state failure behavior (team still owns accounts) and irreversibility. It supplies the precondition but leaves the agent guessing about consequences and error conditions.

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 for teamId and adds nothing: it does not clarify whether teamId is an opaque platform ID or a name, nor where to obtain it. The parameter name is self-explanatory and required, which keeps this at a minimal-viable 3 rather than lower.

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 ("Delete a team") and adds a qualifying precondition ("that no longer owns accounts"), which distinguishes it from create_team/update_team/list_teams. It stops short of naming a sibling or describing the difference in scope, but the action 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 phrase "that no longer owns accounts" implies when deletion is appropriate, but it is not framed as a hard requirement or prerequisite, and no alternative (e.g. remove_team_account, update_team) is mentioned for the case where a team still owns accounts. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false; "Offline — no API call" reinforces and operationalizes that (no network latency, no auth, no side effects), which is genuinely additive context. It stops short of noting whether results are cached or platform-version specific, so not a full 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 short sentences, zero filler: capability first, usage trigger second, behavioral caveat last. Every sentence earns its place.

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

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

For a single optional-param, read-only introspection tool, the description covers what it returns, when to call it, and its cost profile. Only a hint about the response shape (e.g. required vs optional fields) is missing, and no output schema exists to cover that gap.

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

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

Schema description coverage is 100% and the platform property already enumerates every key plus the omit-for-summary behavior. The description only implies per-platform granularity without adding format or matching semantics, so it sits at the baseline.

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

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

"Per-platform publish field schemas and adapter capabilities" states a specific resource and scope that no sibling tool covers — it is a discovery/introspection tool, distinct from create_post and run_account_tool. An agent can tell exactly what it returns 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?

"Call before create_post/create_comment to learn required fields" gives an explicit precondition and names the concrete alternatives it is meant to precede. That is actionable routing guidance, not implied usage.

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, so the safety profile is covered; the description earns credit by going further and enumerating the cascade set (pending schedules, comment automation, inbox, goals, agents) and, importantly, what survives (published history). It stops short of a 5 because it does not say whether reconnection restores anything, whether in-flight posts fail, or whether confirmation is required.

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, zero filler, and the destructive cascade is front-to-back ordered with the preservation guarantee last. Every clause carries decision-relevant information for a destructive call.

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 one-param tool with strong annotations and no output schema, the description supplies the critical missing piece: blast radius and what is retained. A note on reversibility/reconnect semantics would close the remaining gap.

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

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

Schema description coverage is 0% and the description does not mention accountId at all, so it fails to compensate. The gap is partly mitigated because a single required 'accountId' string is self-explanatory, which keeps this at an adequate 3 rather than lower.

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 ('Disconnect') plus a specific resource ('an account'), so the agent knows exactly what call this is. It does not explicitly distinguish itself from the inverse sibling connect_account or state the scope boundary (e.g., that it removes the connection rather than deleting data), so it stops 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?

Usage is implied by the name — call this when an account should be unlinked — but there is no explicit when/when-not statement, no mention of the prerequisite that the account must be currently connected, and no pointer to the alternative (connect_account) for the inverse operation.

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 non-read-only, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely non-obvious context the annotations cannot convey: only Facebook is supported and other platforms return a platform error. It still omits whether the message is fully replaced and what happens if the reply no longer exists.

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

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

A single sentence with the core purpose front-loaded and the platform caveat immediately following. No filler, no redundancy.

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

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

For a mutation tool with three required, zero-documented parameters and no output schema, the description leaves the agent unsure how to obtain itemId/replyId or what a successful edit returns. Only the platform restriction is covered; the operational context is thin.

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% for all three parameters, so the description carries the full burden and supplies nothing about itemId, replyId, or message. The field names are largely self-explanatory and 'message' has a minLength constraint in schema, but there is no guidance on sourcing the IDs or on overwrite 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 (editing an already-sent reply), which distinguishes it from reply_to_inbox_item (creating) and update_comment. It does not name those siblings explicitly, so the differentiation is implicit rather than spelled out.

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 parenthetical clearly scopes applicability ('currently Facebook only'), which implicitly tells an agent when not to call it. However, it never names the alternative for creating a reply versus editing one, nor states prerequisites such as having obtained itemId/replyId via list_inbox.

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=true, so the safety profile is covered. The description adds that token health fields (disconnectedAt / tokenExpiresAt) are surfaced, which is genuinely useful, but says nothing about behavior when the account is missing or the token is expired.

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 compact sentence with the resource and its contents front-loaded; nothing is wasted. The nominal fragment style is terse but readable.

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?

No output schema exists, so the description usefully names the return contents, which is the right thing to do. However, for a lookup tool it omits the one input's meaning and any not-found/error behavior, leaving clear gaps.

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

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

Schema description coverage is 0% and the description does not compensate at all: accountId is never mentioned or explained. The description only talks about returned fields, not about what identifier to supply.

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-implied resource ('One connected account') and enumerates the returned contents: profile, follower count, token health. The singular framing implicitly separates it from list_accounts, though the description never names that sibling.

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

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

Provides no explicit when-to-use or when-not guidance. An agent must infer from 'One' that this is the single-account fetch rather than list_accounts, and nothing is said about refresh_account or check_setup, which could plausibly be chosen instead for token problems.

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 openWorldHint=true, so safety and freshness are covered structurally. The description adds nothing about cost, rate limits, data freshness, or whether results are cached, which matter for a live-analytics read.

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 short sentence with no padding, which is appropriate in size, but it is under-specified rather than efficient—brevity here costs the agent information it 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?

With no output schema and no documented parameters, the description is the only place an agent could learn the return shape and window semantics, and it supplies neither. For an analytics tool with a required ID plus an optional window it is too thin.

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% for both parameters. The phrase 'over a window' gestures at windowDays but gives no units, default, maximum, or allowed range, and accountId format is unexplained, so the description fails to compensate for the empty 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?

Names the resource (an account's engagement summary) and its scope (a time window), but it is a noun phrase with no verb and 'engagement summary' is left undefined, so the agent cannot tell whether this returns counts, rates, or a fixed report. It does weakly differentiate from get_post_analytics by operating at the account level.

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 statement of when to call this versus get_analytics_summary, get_usage, get_post_analytics, or get_best_times, all of which sit nearby and look overlapping. The agent must infer the choice from names 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?

The annotations already declare this is a read-only, non-destructive, open-world operation, so the safety profile is covered. The description adds useful scope detail — only the LATEST row per account, limited to accounts the caller can access, bounded by the window — but says nothing about whether the data is cached versus freshly fetched (relevant given refresh_analytics exists) or how results are shaped.

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

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

One short sentence, front-loaded with the key scope constraint and free of padding. It is efficient, though the terseness borders on under-specification rather than optimal concision.

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

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

With no output schema, an optional undocumented parameter, and a crowded sibling space, the description should explain what a row contains and whether refreshes are needed. It omits all of that, leaving the agent to guess at the return shape and the default window.

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% and the single parameter windowDays has no schema description. The phrase 'in the window' gestures at it but does not state units, default behavior when omitted (it is optional), or any upper bound, so the description does not compensate for the documentation gap.

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

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

The description names the resource (analytics rows) and a scope (latest row per accessible account within a window), which is more specific than the title alone. But it has no verb and does not distinguish itself from close siblings such as get_account_analytics, get_bulk_post_analytics, and get_usage, so an agent cannot confidently pick it over those.

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 statement of when to use this tool, when not to, or which sibling it replaces. With four other analytics-related tools in the list (get_post_analytics, get_account_analytics, get_bulk_post_analytics, refresh_analytics), the absence of routing guidance is a real gap.

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

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

The annotations already establish that this is a safe, read-only, open-world operation. The description adds useful context by saying the recommendations derive from engagement history and can be scoped per account, but it does not cover freshness, return shape, or limitations.

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

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

The description is a single front-loaded sentence with no filler. It conveys the core purpose and optional scoping efficiently.

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

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

For a simple read-only tool with one optional parameter and annotations covering safety, this is adequate for selection. However, because there is no output schema, the description could say more about the format and granularity of the returned recommendations.

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

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

There is one optional parameter, accountId, with 0% schema description coverage. The phrase 'optionally per account' signals that account scoping exists, but it does not clarify whether passing accountId returns only that account's recommendations or a per-account breakdown.

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

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

The description clearly states the resource, 'recommended posting times,' and the source, 'engagement history,' with optional per-account scope. It is understandable without opening the schema, though it does not explicitly differentiate itself from sibling analytics 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?

Usage is implied: an agent would call this when it needs recommended posting times based on prior engagement. However, there is no explicit guidance on when to prefer this over analytics tools or when not to use it.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety is covered. The description adds one genuinely useful behavioral trait beyond that: per-post errors are returned rather than failing the whole batch. It does not describe the error shape, platform-level gaps, or whether partial data still returns.

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 clause, front-loaded with the resource and the batch limit, with the error behavior appended. No filler, though the fragment lacks a verb and reads more like a label than a sentence.

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

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

For a one-parameter read tool with annotations covering the safety profile and no output schema, the description supplies the two things an agent needs: the batch limit and the partial-failure contract. Little more could be expected at this 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 0%, so the single postIds parameter is undocumented in the schema. The description restates the 60-item cap (already enforced by maxItems) but adds no meaning about ID format, where to source the IDs, or behavior when an ID is invalid — only partial compensation for the coverage gap.

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

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

States a specific resource and scope: analytics for a batch of up to 60 posts. The batch scope implicitly distinguishes it from the sibling get_post_analytics, though no verb ('retrieve'/'fetch') and no explicit sibling callout make the distinction inferential 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?

The 'up to 60 posts' framing implies this is the batch path versus the single-post get_post_analytics, but the description never says when to prefer one over the other, nor what to do for more than 60 posts. Usage is implied only.

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 safety and reach are covered elsewhere. The description adds value by disclosing the shape of the response (stage, picks, mediaId, postIds), which matters because no output schema exists, but it says nothing about failure modes or what values 'stage' can take.

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 short sentence with the subject front-loaded and no filler. It is economical, though the compressed phrasing ('stage, picks') is slightly jargon-heavy for an agent without domain context.

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

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

For a one-parameter read tool with no output schema, the description does cover the returned fields, which is the main burden. It still omits how to obtain a clipId and how this relates to list_clips/get_clip_usage, leaving the workflow context incomplete.

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% and the single parameter clipId is undocumented in both schema and description. 'One clipping job' hints that clipId selects the job, but nothing states where a clipId comes from (presumably list_clips or create_clip) or its format, leaving the parameter gap unresolved.

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

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

The description names the resource (a single clipping job) and enumerates what it carries: stage, picks, and per-clip results (mediaId, postIds). The singular 'One clipping job' implies retrieval and implicitly distinguishes it from list_clips, but no verb is stated and no sibling is named explicitly, so differentiation is inferential 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?

There is no guidance on when to call this versus list_clips, get_clip_usage, or create_clip. The agent must infer that this is the detail-fetch for a known clipId, with no prerequisites, exclusions, or alternative routing given.

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=true, so the safety profile is covered. The description adds the useful detail that the result is a comparison of used minutes against a plan limit. It does not address which account/workspace the usage is scoped to, which matters for a zero-parameter, open-world tool.

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

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

A single short sentence with zero filler, and the key concept (minutes used vs. plan limit) is front-loaded. For a zero-parameter read tool there is nothing to trim and nothing padded.

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

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

With no parameters and no output schema, the description carries the full burden of explaining what comes back, and it only sketches the shape (a used-vs-limit figure). It never states the account scoping or the unit/format of the limit, which are real gaps for an agent assembling a usage report.

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 there is no parameter semantics to explain and the baseline is 4. No schema burden is being shirked 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?

The phrase names the specific resource and metric: clipping minutes consumed against the plan limit. That is more than a restatement of the name and tells an agent exactly what is returned. It stops short of differentiating from the sibling get_usage, so the boundary between general usage and clip-specific usage is left to inference.

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 when-to-use guidance, no exclusion, and no mention of the obvious sibling alternative get_usage. An agent with a question about plan consumption has no stated rule for choosing between get_usage, get_account_analytics, and get_clip_usage.

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=true, so the safety profile is covered externally. The description adds only the word 'scheduled' (implying scope to comments on scheduled posts) and says nothing about behavior on a missing/unknown commentId or auth requirements.

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

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

A single short sentence with the resource front-loaded and zero filler. It is efficient, though so terse that it borders on under-specification rather than wasteful phrasing.

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

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

For a lookup tool with one undocumented parameter and no output schema, the description omits what is returned (comment fields, author, status) and where the commentId comes from. An agent can guess, but nothing needed for reliable invocation is supplied.

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% — commentId is typed only as a bare string with no format, source, or example. The description never mentions the parameter, so it does not compensate for the documentation gap as required at low coverage.

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

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

States a specific verb (Fetch) and resource (one scheduled comment), which distinguishes it from list_comments and create/update_comment by name alone. It stops short of explicitly naming a sibling or scoping the distinction, so not 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?

There is no guidance on when to use this instead of list_comments, get_post, or the comment-mutating siblings. The agent must infer that a commentId must already be known and come from a list operation.

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, and destructiveHint=false, so the safety profile is covered. The description adds almost nothing beyond the verb – it does not state that it requires a valid media ID, what happens if the item is missing, or what kind of data is 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?

The sentence is short and front-loaded with no wasted words, but its brevity reflects under-specification rather than efficient communication. It is appropriately sized only because the tool is very simple.

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

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

For a one-parameter read tool with no output schema, the description should at least clarify that it returns media metadata and how to identify the media item. With annotations covering safety but no explanation of return values or ID semantics, the definition is incomplete for reliable 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% for the single parameter, mediaId. The description does not compensate by explaining what mediaId refers to, whether it is an internal or platform ID, or what format it takes.

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 gives a specific verb and resource ('Fetch one media item') and the singular 'one' implicitly distinguishes it from sibling list_media. It stops short of naming the sibling alternatives or clarifying the identifier-based lookup, but an agent can still understand its purpose.

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

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

There is no guidance on when to use this tool versus list_media or get_clip, and no prerequisites or conditions are mentioned. The agent must infer that it is for retrieving a single item by ID.

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=true, so safety is covered. The description adds only a hint of what is returned (plan, limits, connected-account summary), with no mention of permissions, freshness, or whether it reflects a cached snapshot.

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 only five words, so there is no waste, but it is a sentence fragment rather than a front-loaded statement of purpose and effect. Brevity here comes at the cost of specification rather than from efficient editing.

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

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

With no output schema, the description carries the burden of explaining return values, and it names three content groups (plan, limits, connected accounts) — a partial compensation. However, it omits what 'limits' means (rate limits vs plan quotas) and the shape/scope of 'connected-account summary', leaving the response partially opaque.

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 the baseline is 4; there is nothing for the description to disambiguate. An empty input schema is self-explanatory.

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 fragment 'Plan, limits, and connected-account summary' signals the resource content (organization-level plan/billing/connections) but never uses a verb or names the resource, so the agent must infer that it retrieves the current organization. It does implicitly differentiate from siblings such as get_usage or get_account by scoping to plan/limits/connected accounts, but the distinction is left to inference.

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 statement of when to call this versus list_accounts, get_account, get_usage, or check_setup, nor any prerequisite or exclusion. The agent is given content hints but no routing guidance among many overlapping org/account siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so safety and external-dependency behavior is covered. The description adds value by disclosing the shape of the result (nested accounts with permalinks and overrides, plus media), but says nothing about behavior on a missing or inaccessible postId, nor about pagination or size.

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 that names the resource and the returned components with zero filler. Every clause ('accounts (permalinks, overrides)', 'media') conveys actual content.

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

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

With no output schema, the description does a fair job sketching return contents, and annotations cover the read-only profile. However, for a getter the agent still lacks guidance on identifier semantics and failure modes, which are the two things that actually affect a correct call.

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

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

Schema coverage is 0%, so the description must carry the burden for postId, and it does not. It never says whether postId is the internal post identifier versus an external/platform post ID, nor what format is expected. This is a real ambiguity for the single required parameter.

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

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

The verb and resource are explicit ('Fetch one post') and the singular 'one' implicitly distinguishes it from list_posts. It also names what is returned (accounts, permalinks, overrides, media), giving a concrete picture of the payload. It stops short of naming the sibling explicitly, which keeps it out of 5 territory.

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

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

Usage is only implied: fetching by a single postId suggests retrieving a known post rather than browsing, which contrasts with list_posts. There is no explicit when-to-use, when-not-to-use, or pointer to an alternative such as list_posts or get_post_analytics.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds only a partial list of returned metrics; it says nothing about freshness/lag of analytics, supported platforms, time-window behavior, or permissions, which are the real unknowns for an open-world analytics read.

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 front-loaded and wastes nothing, but at a single sentence fragment it reads as under-specification rather than disciplined brevity. Nothing in it could be cut, but much is missing.

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 no output schema, the description is at the edge of adequacy: it names the return content, which is the main thing the missing output schema would have covered. It still omits ID format, metric time window, and platform scope, which an agent needs before calling.

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% for the single postId parameter, so the description carries the full burden — yet it only implies 'a post' without specifying the ID format (internal platform ID vs. this API's ID) or whether cross-account IDs are valid. That ambiguity will cause failed invocations.

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?

It states the resource precisely — metrics for a single post — and parenthetically names the metric families (likes, comments, reach). It does not use a verb or explicitly contrast itself with the obvious sibling get_bulk_post_analytics, so the agent must infer the single-vs-bulk split.

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 when-to-use guidance, no prerequisites, and no mention of the alternative bulk or account-level analytics tools in the sibling list. The word 'One' hints at single-post scope but the routing decision is left entirely 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered elsewhere. The only added behavioral signal is the word 'summary', which weakly suggests an aggregated view rather than raw rows, but it discloses nothing about error behavior for missing/expired jobs or what fields come back.

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 only a sentence fragment, so there is no waste, but this is under-specification rather than conciseness. There is no front-loaded verb or scope statement, and the single noun phrase carries almost no information.

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

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

For a read-only single-record fetch this should be easy to complete: identify the ID's origin, contrast with the rows and list siblings, and note whether a missing job errors or returns empty. None of that is present, and with no output schema the description is the only source for what comes back.

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 bears full responsibility for explaining jobId - its format, where to obtain it, and whether it is the import ID or something else. It says nothing, leaving the sole required parameter unexplained in both the schema and the prose.

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 name plus 'One import job's summary' conveys that this retrieves a single CSV import job record rather than a list, which loosely separates it from list_post_csv_imports. But 'summary' is ambiguous - it could mean aggregate counts, status metadata, or a truncated row set - and the description never states what is actually being fetched. An agent can guess the resource but not the content.

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 call this instead of list_post_csv_imports or get_post_csv_import_rows, and no mention that a valid jobId from the list endpoint is a prerequisite. The word 'One' hints at a single-record lookup but the choice among the three sibling import tools is left entirely 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine content information — that results are per-row and status-tagged SUCCESS/FAILED — but says nothing about pagination behavior, whether rows are available before job completion, or result volume despite limit/offset existing.

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 short sentence, front-loaded with the resource being returned and no filler. It is efficient, though the brevity comes at the cost of the specification gaps scored elsewhere.

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

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

With no output schema, 0% parameter description coverage, and four parameters including pagination, the description is far too thin. An agent would not know how rows are shaped, how to page, or how to filter without reverse-engineering the schema.

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

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

Schema description coverage is 0% across 4 parameters, so the description carries the full burden and fails to explain jobId, limit (max 500), offset, or that status filters to SUCCESS/FAILED. The mention of SUCCESS/FAILED only echoes the enum already present in the schema rather than explaining filter semantics.

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

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

The description names the specific resource — per-row SUCCESS/FAILED results for an import job — which clearly distinguishes it from job-level siblings like get_post_csv_import and list_post_csv_imports. It lacks an explicit verb ('retrieve'/'get'), but the noun phrase is precise enough to identify the 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?

There is no statement of when to call this versus get_post_csv_import (job summary) or list_post_csv_imports (job listing), and no prerequisites such as requiring a completed job. The agent must infer the call context entirely.

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=true, so the safety profile is covered. The description adds only the hint that member accounts are bundled into the result; it says nothing about failure modes (unknown teamId), permissions, or the shape/size of the membership list, which would genuinely help for an open-world read.

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 short fragment with no filler, so nothing is wasted, but it is under-specified rather than concise: no verb, no sentence structure, and the key scoping fact (one team, identified by teamId) is implied rather than front-loaded.

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

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

For a one-parameter read with no output schema and no parameter docs, the description should at minimum say it fetches a team by ID and what the membership payload contains. Neither is present, so an agent cannot fully predict inputs or outputs from the definition.

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

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

Schema coverage is 0% and the single required parameter 'teamId' is completely undocumented — the description never mentions it, its format, or where to obtain one. With exactly one parameter, an extra clause would have been cheap, so the omission is a real gap rather than a baseline 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 fragment 'One team with its member accounts' gestures at retrieving a single team plus its members, but never states a verb and essentially restates the name 'get_team'. It does add one real detail (members are included), which barely lifts it above pure tautology, and it offers no differentiation from siblings like list_teams or get_organization.

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 when-to-use guidance, no prerequisite (e.g. a teamId being required), and no mention of the very plausible alternatives in the sibling set (list_teams for enumeration, get_organization for org-level data, get_account for member lookups). The agent must infer everything.

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

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

The annotations already establish that this is a safe read-only operation with no destructive behavior. The description adds useful context about what data is returned, but it does not disclose freshness, account scoping, or output format.

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

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

The description is a single compact sentence fragment that front-loads the key returned metrics. Every phrase contributes information, with no filler or repetition.

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

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

For a zero-parameter read-only tool with annotations covering safety, the description sufficiently conveys the main returned data. Minor details such as whether usage is account-scoped or how values are formatted are not covered, preventing a 5.

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

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

The tool has zero parameters, so there are no parameter semantics for the description to clarify. The baseline score of 4 applies because the description does not need to compensate for undocumented inputs.

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

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

The description clearly identifies the data returned: monthly post usage, plan limit, and credit balance. It does not explicitly distinguish this tool from the sibling get_clip_usage, 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?

There is no explicit guidance on when to use this tool, when to choose an alternative such as get_clip_usage, or what context makes it appropriate. The intended use is only implied by the returned metrics.

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, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful detail about the returned fields, but does not mention pagination, authentication requirements, or whether all accounts are returned by default.

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 fragment with no wasted words. However, it is so terse that it lacks a clear verb and structure beyond listing fields.

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

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

For a simple read-only list tool with one optional parameter and no output schema, the description mentions the returned fields but omits pagination behavior and any scope information. It is minimally adequate but does not help the agent route among many account-related siblings.

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

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

Schema description coverage is 100%, and the single optional 'platform' parameter is documented as 'Filter by platform key' in the schema. The description adds no additional parameter meaning, which is acceptable given the schema already covers it.

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

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

The description identifies the resource as connected social accounts and lists the returned fields (id, platform, username). This is clear enough to understand the tool's purpose, but it does not explicitly differentiate it from related siblings like get_account or list_account_tools.

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

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

The description provides no guidance on when to use this tool versus alternatives such as get_account for a single account or list_account_tools for account-specific tools. Usage is only implicitly suggested by the tool 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 declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true. The description adds meaningful context beyond that by clarifying the results are live external lookups whose contents vary by platform (Reddit flairs, Pinterest boards), but says nothing about rate limits, auth failures, or what happens for unsupported platforms.

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 efficient sentence with the core concept front-loaded and no wasted words. It is arguably too short for the information an agent needs, but it is structurally clean.

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

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

For a simple read-only tool with no output schema and one parameter, the description still leaves significant gaps: it never mentions accountId, never indicates the return shape (tool names? identifiers?), and never connects the list to run_account_tool. The annotation coverage helps, but the workflow linkage is 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?

Schema description coverage is 0% and the single required parameter accountId is never mentioned in the description. The phrase 'the account's platform' only weakly implies per-account scoping; no ID format or source is given to compensate for the undocumented 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 identifies the resource (per-account live lookups for the account's platform) and gives concrete examples, so an agent can tell this enumerates platform-specific tools. However, there is no explicit verb like 'list' and no direct contrast with run_account_tool, the sibling that actually executes these lookups, leaving the boundary between the two 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?

No when-to-use or when-not-to-use guidance is given. The description never mentions run_account_tool, which is presumably the consumer of this list, so the discovery-then-execute workflow has to be inferred entirely by the agent.

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=true, so safety is covered. The description adds that results carry stage and results fields, which is useful, but it doesn't say what 'recent' means (time window, ordering, default page size) or whether results are scoped to an account.

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?

Very short and front-loaded with no filler, but it is a sentence fragment rather than a statement of what the call does, so brevity comes at the cost of a missing verb and missing 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?

There is no output schema, so the description's note about stage and results is welcome, and annotations cover the read-only profile. Still missing for a listing tool: default ordering/window implied by 'recent', default limit, and whether jobs are filtered by account.

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% for the single 'limit' parameter (integer, 1-20, optional), and the description never mentions it, its default, or its maximum. An agent gets no help on whether to pass it or how results are bounded.

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 fragment 'Recent clipping jobs with their stage and results' indicates the resource (clip jobs) and roughly what is returned, but has no verb and never says 'list'. It is distinguishable from get_clip only by inference, not by explicit contrast.

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 when-to-use guidance and no mention of the obvious alternatives (get_clip for a single job, get_clip_usage for quota, create_clip for starting one). The word 'recent' hints at a browse-style call but nothing states the selection condition.

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=true, so the safety profile is covered. The description adds only the implicit behavioral hint that results are limited to scheduled comments for one post — it says nothing about ordering, pagination, or whether non-scheduled comments are excluded.

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?

Extreme brevity here is under-specification, not conciseness: a single four-word fragment that omits the action entirely. There is nothing to front-load because almost no information is present.

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

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

With 0% schema description coverage, no output schema, and no parameter explanations, the definition leaves essential gaps for an agent — most critically what the status filter does and what the returned set represents. The annotations cover safety but not semantics.

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% for 2 parameters, so the description carries the full burden — yet it only vaguely implies postId ("for a post"). The status enum (pending/published/failed) is never explained, nor whether it filters scheduled comments by delivery state.

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 text is a noun fragment, "Scheduled comments for a post," with no verb stating that it lists or retrieves anything. It adds a modicum of scope beyond the name (scheduled-only, per-post) but does not distinguish it from siblings like get_comment or list_inbox.

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 statement of when to use this vs get_comment (single comment), list_inbox (inbox items), or create_comment/schedule-like flows. The agent must infer usage purely from the tool name and the presence of a postId requirement.

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, openWorldHint, and destructiveHint=false. The description adds useful scope by noting the items span 'accessible accounts' and cover multiple content types, but it does not disclose pagination defaults, ordering, or return behavior.

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

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

The description is a single compact sentence with no wasted language and is front-loaded with the core resource. However, it is a fragment rather than a structured sentence and leaves the agent with minimal invocation guidance.

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

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

Given six parameters, no output schema, and no parameter descriptions, the definition is materially incomplete. It should explain filtering, pagination, default behavior, and what the returned inbox items contain.

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

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

There are six parameters with 0% schema description coverage, and the description does not explain any of them. It gives no guidance on limit, offset, status, platform, accountId, or sourceType, so the low schema coverage is not compensated for.

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 incoming comments, mentions, and DMs across accessible accounts, which clearly differentiates it from post-specific tools like list_comments. It lacks an explicit verb, but the tool name and title supply 'list', so the purpose is still clear.

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

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

There is no guidance on when to use list_inbox versus alternatives such as list_comments or reply_to_inbox_item. It also omits any conditions, prerequisites, or exclusions for retrieving inbox items.

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=true, so the safety profile is covered. The description adds nothing beyond restating the title: no default page size, no ordering, no statement of what the open-world read actually touches. With annotations carrying the load, this earns only partial credit for the absent behavioral detail.

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

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

It is a single front-loaded sentence with zero waste, which is structurally sound. The brevity is under-specification rather than efficiency, so it does not earn a top score for conciseness when the content is this thin.

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 three optional parameters, no output schema, and no description of return shape, defaults, or pagination behavior, an agent cannot call this confidently without trial and error. Annotations cover safety but not the operational detail a list tool needs.

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% across three parameters. The description does not mention the type filter, the limit cap of 100, the default page size, or that offset is a zero-based page cursor. The enum on 'type' is the only self-documenting element, leaving limit and offset semantics undefined.

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 uploaded media" gives a clear verb and resource, so the basic action is unambiguous. But it never distinguishes itself from siblings like get_media, list_posts, or list_clips, nor does it state what 'media' covers or whether results are scoped to an account. That is minimum viable, not a distinguishing definition.

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 list_media versus get_media (single item) or how to page through results with limit/offset. The agent must infer the list-vs-get relationship and pagination strategy entirely from tool names.

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=true, so the safety profile is covered. The description adds two useful facts — results are scoped to the caller's own imports and each entry includes counts — but says nothing about pagination behavior or ordering.

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

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

A single compact sentence with the scope ('caller's') front-loaded. Efficient, though the brevity is partly under-specification rather than tightness.

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?

No output schema exists, so the description would need to characterize the returned job records and counts, and it doesn't. Combined with undocumented pagination parameters and no sibling disambiguation, an agent has to guess at both call shape and response shape.

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

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

Both parameters (limit, offset) have 0% schema description coverage, only bare min/max constraints, and the description supplies no meaning for them — no default limit, no indication whether pagination is required for full results. With low coverage the description should compensate and it does not.

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

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

Names the resource (CSV import jobs), scopes it to the caller, and hints at the return payload ('with counts'). However it lacks an explicit verb and does nothing to distinguish it from the very similar siblings get_post_csv_import, get_post_csv_import_rows, and create_post_csv_import.

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 at all on when to call this versus get_post_csv_import (single import) or get_post_csv_import_rows (row-level data). The agent must infer from names alone which listing tool to use.

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, openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that structured data: no note on ordering, default page size, total counts, or what a broad openWorld query might return, leaving real behavioral gaps for a listing tool.

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

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

A single short, front-loaded sentence with no padding, but its brevity stems from under-specification rather than efficiency. It could afford a clause on scope or pagination defaults.

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 4-parameter, open-world listing tool with no output schema and 25% schema coverage, the description omits essential invocation context: pagination mechanics (offset/limit semantics, defaults, cap), result ordering, and whether results are scoped to a connected account. Too much must be guessed.

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 25%: q is documented as a caption substring filter, but limit, offset, and status are bare (only max/min and an enum). The description's 'optional filters and pagination' does not compensate, giving no defaults, no max page guidance (limit caps at 100), and no filter 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?

The name/description pair states a clear verb+resource (list posts), so the basic action is unmistakable. However, the qualifier 'optional filters and pagination' just restates properties of the input schema, and nothing distinguishes this from get_post or the many other list_* siblings or clarifies scope (account-scoped? workspace-wide?) as openWorldHint implies.

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 get_post, get_post_analytics, or list_comments, and no mention of preconditions such as needing a connected account. The agent must infer usage entirely from the 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 declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile needs no restating. The description's one value-add is that results are denormalized with member accounts embedded, which tells the agent something about payload shape that the (empty) input schema cannot.

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 with zero filler and the scope qualifier front-loaded after the resource. It is a noun fragment rather than a clause, which is mildly under-specified, but nothing is wasted.

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

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

There is no output schema, so the description carries the burden of describing the return shape; it partially does so by noting embedded member accounts. It says nothing about pagination, result volume, or what fields a team record holds, which are the remaining gaps for a listing tool in a workspace of 40+ siblings.

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 there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter semantics are missing or misstated.

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 fragment "Teams with their member accounts" identifies the resource and, via the tool name list_teams, implies enumeration, so an agent can guess the operation. But there is no explicit verb in the description and nothing distinguishes it from siblings like get_team, list_accounts, or describe_platform.

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 call this versus get_team (single team) or list_accounts (accounts as the primary resource). The 'with their member accounts' clause hints at a use case but never states the selection condition.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context that the refresh happens server-side, implying the token is not returned to the caller, but it does not address auth requirements, token invalidation, idempotency, or failure 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?

A single front-loaded sentence with no waste. Every element (refresh, OAuth access token, server-side) earns its place.

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

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

For a simple one-parameter mutation with annotations and no output schema, the description is minimally adequate. However, it omits when the tool should be used, whether the existing token is invalidated, and what the caller should expect on success or failure.

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% for the single accountId parameter. The description indirectly clarifies that accountId identifies the account whose OAuth token is refreshed, which is modest added meaning, but it provides no format, source, or examples.

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 (refresh an account's OAuth access token) and adds the 'server-side' qualifier, which distinguishes it from siblings like refresh_analytics or connect_account. It does not explicitly name alternatives, so it stops short of full sibling differentiation.

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

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

There is no guidance on when to call this versus alternatives such as connect_account or check_setup, nor any prerequisite (e.g., expired token, existing connection). The implied usage is only that a token can be refreshed, leaving the agent to infer 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 it is non-read-only, non-destructive and open-world, so the safety profile is covered. The description adds genuine value by disclosing that the operation is asynchronous and returns a job id, but says nothing about whether the backfill overwrites existing analytics, how long it takes, or any rate/cost limits for an open-world 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?

A single tight sentence with the action, async nature, target scope and return value all front-loaded. Nothing wasted, nothing buried.

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

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

For a four-parameter, zero-required, no-output-schema mutation tool, the description is too thin. It partially compensates for the missing output schema by mentioning the job id, but leaves the postId/accountId relationship and the limit/windowDays semantics undocumented, which is exactly what an agent needs to construct a valid call.

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

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

Schema description coverage is 0% across four parameters. The description's 'for a post or account' loosely maps to postId and accountId but never states whether they are mutually exclusive or which takes precedence, and 'limit' and 'windowDays' — clearly meaningful controls on backfill scope — are entirely unexplained.

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 gives a specific verb plus resource — 'Enqueue an async analytics backfill' — with a stated scope of 'a post or account' and notes a job id is returned. This implicitly separates it from the read-oriented get_post_analytics/get_account_analytics siblings, but it never names or contrasts with them or with refresh_account.

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 statement of when to call this versus the many analytics read tools (get_post_analytics, get_account_analytics, get_analytics_summary) or versus the near-identical sibling refresh_account. The agent must infer that 'backfill' means refreshing stale data rather than reading 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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds important behavioral context beyond annotations: the account is not deleted but reassigned to the default team, which materially affects how an agent should reason about the operation's side effects.

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

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

The description is a single, front-loaded sentence with no filler. Every phrase contributes either the core action or the key behavioral consequence.

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

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

For a simple two-parameter mutation tool whose annotations already cover destructiveness and openness, the description gives the critical outcome: reassignment rather than deletion. It leaves parameter semantics undocumented, but the required identifiers are self-evident and no output schema exists that needs explaining.

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

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

There are two required parameters, teamId and accountId, with 0% schema description coverage. The description implies that the parameters identify a team and an account, but it provides no additional meaning, format, or constraint beyond that implication.

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: 'Remove an account from a team.' It also distinguishes the action from deleting an account by clarifying reassignment to the default team, and it is clearly differentiable from sibling tools like add_team_account and delete_team.

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

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

Usage is implied by the action: use it to remove an account from a specific team. However, the description does not explicitly state when to use this versus alternatives such as add_team_account, update_team, or delete_team, nor does it mention prerequisites 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 declare readOnlyHint=false, openWorldHint=true, and destructiveHint=false, so the safety profile is structured. The description adds nothing beyond the name: no note that the reply is sent externally and is visible to users, no idempotency or duplicate-reply behavior, no error conditions.

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 short sentence is front-loaded and free of waste. It is arguably too terse for the amount of undocumented behavior, so brevity comes at the cost of utility rather than being 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 mutating, externally visible tool with 0% schema coverage and no output schema, the description leaves out how to obtain a valid itemId, what a successful reply returns or looks like, and how failures surface. An agent would be guessing on the first call.

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

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

Schema description coverage is 0% for two required parameters. The description implies itemId is a comment/mention/DM identifier but gives no format or provenance, and says nothing about whether message accepts mentions, links, or media. It does not compensate for the missing schema descriptions.

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

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

States a specific verb and resource ('Reply to... inbox item') and clarifies what an inbox item is (comment/mention/DM), which meaningfully narrows the object. It does not distinguish itself from siblings like edit_inbox_reply or create_comment, so an agent cannot tell from the text alone which to pick.

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 create_comment, edit_inbox_reply, or get_comment. There is no mention of prerequisites such as the item needing to exist or belong to the connected account.

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 non-read-only, non-destructive, open-world behavior, so the bar is lower, but the description adds nothing: it doesn't say what happens if the post is already published, whether re-scheduling is allowed after failure, or what constraints exist on the new time.

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 short sentence with the key concept front-loaded and no waste, but it is terse to the point of under-specification rather than genuinely economical.

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

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

For a mutation tool with no output schema, partial parameter coverage, and several sibling tools that also touch scheduling, the description says far too little about effects, failure cases, and required account/post state.

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 50% schema coverage, and the undocumented parameter postId is not explained in the description. The '(ISO 8601)' hint merely repeats the schema's own description of scheduledAt, adding no new 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+resource: moving a post's target time, with the ISO 8601 note. It does not distinguish itself from close siblings like schedule_post, update_post, or create_post, so an agent must infer the boundary.

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

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

No indication of when to use this versus schedule_post (which presumably sets an initial time) or update_post (which may also change scheduled fields). No prerequisites or exclusions are mentioned.

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 mutation profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds only that the target must be pending/failed and that publishing happens immediately, with nothing about what happens on failure, whether retries are rate limited, or whether the comment is re-scheduled versus published immediately.

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

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

One short sentence, front-loaded with the action and qualified by state; nothing is wasted. Terseness here is close to under-specification, but the sentence itself has 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?

A mutating, open-world tool with no output schema and an undocumented parameter needs more: which states are retryable, what the caller gets back, and what failure means. The description supplies basically one fact (target state), leaving key call-time knowledge 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 0% for the single required commentId, so the description carries the burden. It only implies the ID belongs to a pending/failed comment; it states nothing about whether the ID must be in a retryable state, what error occurs otherwise, or the accepted ID format.

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?

"Publish a pending/failed comment now" gives a specific verb (publish) and resource (comment) plus a state qualifier (pending/failed) that separates it from create_comment and update_comment. It does not explicitly name the closest relatives (retry_post, reply_to_inbox_item), so it stops 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 mention of pending/failed comments implies the condition under which to call it, but no alternatives are named and no exclusion is stated (e.g., "use create_comment for a new comment"). An agent must infer when this is the right choice versus create_comment or reply_to_inbox_item.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the safety profile is covered. The description adds that only failed schedules are affected (successful ones untouched), but says nothing about what happens to already-succeeded deliveries, rate limits, or the result of the retry.

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 zero filler; the distinguishing qualifier 'failed' appears early.

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

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

For a one-parameter mutation with no output schema, the description leaves open whether *all* failed schedules are retried or only the most recent, and what the caller gets back (counts, errors). Adequate but with clear gaps.

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

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

Schema description coverage is 0% — postId is a bare string with no format hint. The description only implies 'a post' via the possessive, giving no guidance on whether this is the internal post ID or a platform-native one, which matters given many sibling tools also take postId.

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: re-queue a post's *failed* schedules. The qualifier 'failed' separates it from reschedule_post and retry_comment/retry_post_csv_import, though it never names those siblings 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?

Implies the trigger condition (schedules that already failed) but gives no explicit when-to-use vs. reschedule_post or update_post, and no prerequisites such as post state or account connectivity.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the meaningful detail that only failed rows are re-run rather than the whole job, but says nothing about idempotency, whether duplicate rows can be created, whether the call is async, or what happens when no failed rows exist.

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

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

One short sentence, front-loaded with the action and with no filler. It is efficient, though its brevity borders on under-specification given the undocumented parameter and absent return semantics.

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

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

With no output schema, the description should say what comes back (a new job id, a count of retried rows, or a status), and with 0% parameter coverage it should identify the jobId source. Neither is present, so a caller cannot predict the result or supply the input confidently.

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 jobId has 0% schema description coverage, so the description carries the full burden and provides nothing — it never mentions the parameter, its expected source (e.g., from list_post_csv_imports or get_post_csv_import), or its format. The agent must guess which job identifier to pass.

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?

A specific verb ('re-run') plus resource ('an import job's failed rows'), with the added scope detail that only failed rows are reprocessed, which separates it from create_post_csv_import. It does not explicitly name the sibling it complements (get_post_csv_import / get_post_csv_import_rows), so an agent must infer the relationship.

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 'failed rows' implies the pre-condition that a prior import partially failed, but there is no explicit when-to-use, when-not-to-use, or pointer to the sibling tools that surface failed rows. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds real context beyond that: the two supported tool names and the exact input payload each expects ({ subreddit } vs {}), which is not recoverable from the schema. It stops short of describing what the lookup returns or any per-platform failure modes.

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

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

Two compact sentences: the operation and its variants come first, the usage trigger second. No filler, and the per-tool input shapes are parenthetically inlined rather than given their own bloated section.

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

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

There is no output schema, so the description should ideally say what a lookup yields (a list of flairs with ids, a list of boards with ids) so the agent knows how to feed the result into create_post. That return-shape gap, plus the undocumented accountId, leaves it adequate but incomplete for a dispatcher tool.

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

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

Schema coverage is only 33% and the `tool` parameter has no enum, so the description carries the burden of enumerating valid values and their payload shapes — it does this well for `tool` and `input`. `accountId` remains undocumented in both schema and description, which keeps it below 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?

States a specific verb and resource ('Run a per-account lookup') and enumerates the concrete operations available (reddit-flairs, pinterest-boards) with their input shapes. It is distinguishable from siblings like list_account_tools, though that relationship (this is the executor for the tools that tool lists) is only implied via the schema's parameter description 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?

'Use before creating posts that need a flair or board id' gives an explicit triggering condition and ties the tool to a downstream action. It does not state when-not-to-use or clarify that a prior list_account_tools call is required to obtain a valid tool name, leaving that sequencing 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?

Annotations already declare readOnlyHint=false, openWorldHint=true, destructiveHint=false, so the safety profile is covered. The description adds no further behavioral context — no mention that content is published to external platforms, no timezone or past-time validation behavior, and no side effects beyond the obvious. It largely restates schema content (ISO 8601 format).

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

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

A single front-loaded sentence with zero wasted words. It is efficiently structured, though its brevity leaves little room for the context an 8-parameter publishing tool ideally 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?

For a mutation tool that publishes to external platforms with 8 parameters and no output schema, the description is thin. It does not explain scheduling semantics (past times, timezone handling), the thread/override composition, or what an agent gets back, leaving important gaps despite full 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 description coverage is 100%, so all 8 parameters (caption, mediaIds, postType, accountIds, scheduledAt, threadParts, firstComment, accountOverrides) are already documented. The description's 'ISO 8601' example duplicates the scheduledAt schema text and adds no semantics for threadParts or accountOverrides, 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?

States a specific verb and resource ('Create a post') plus the scheduling constraint ('scheduled for an ISO 8601 time'), which implicitly contrasts with create_post (immediate publish) and distinguishes it from reschedule_post. However, it never explicitly names either sibling or clarifies the boundary, so an agent must infer the routing.

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 when-to-use or when-not-to-use guidance, no prerequisites (connected accounts, valid media), and no named alternative for rescheduling existing posts. The scheduling intent is only implied by the word '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 declare this is a non-destructive mutation on an open-world surface, so the safety profile needs no restating. The description adds the meaningful constraint that only pending comments can be edited and that fields may be updated independently, but says nothing about error behavior for non-pending comments or whether text replaces existing content.

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 verb and resource, with the scoping qualifier and optional-field hints packed in without 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?

Adequate for a simple three-field mutation whose annotations carry the safety profile, and 'and/or' clarifies partial updates. Still missing the scheduledAt format and the behavior when a comment is not pending, both of which the agent would need before calling.

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

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

Schema description coverage is 0%, so the description must compensate. It maps two of the three parameters ('text', 'due time' = scheduledAt) but ignores the required commentId and gives no format for scheduledAt, leaving a real gap given zero schema documentation.

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

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

States a specific verb and resource ('Edit a ... comment'), and narrows scope with 'pending' and the editable fields ('text and/or due time'), which separates it from create_comment and delete_comment. It does not explicitly name sibling tools, so sibling differentiation is implied 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?

'pending' implies a precondition for use, and 'and/or' implies partial updates are allowed, which is useful. However, no alternative is named (e.g., edit_inbox_reply vs update_comment) and no explicit when-not guidance is given.

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 that this is a non-read-only, non-destructive mutation. The description adds useful behavior beyond that—particularly that setting scheduledAt to null clears the schedule and returns the post to draft—but it does not cover permission requirements, media replacement semantics, status-transition rules, or how accountOverrides behave.

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

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

The description is a single front-loaded sentence with no filler, and each listed field corresponds to an editable aspect of the post. It is compact and scannable, though the parenthetical scheduling note and bare field list are somewhat terse.

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 12-parameter mutation with minimal schema documentation and no output schema, the description is too thin. It names several editable fields but leaves key parameters and behavioral details undocumented, so an agent would still need to infer a lot before invoking it safely.

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 8%, so the description must carry most of the parameter meaning. It maps a few fields (caption, media to mediaIds, schedule to scheduledAt, status, poll, thread to threadParts), but omits important parameters including the required postId, accountIds, accountOverrides, delayMinutes, firstComment, and postType.

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 gives a clear verb and resource ('Partially update a post') and enumerates the fields that can be changed. It does not explicitly distinguish this tool from nearby siblings such as reschedule_post or schedule_post, which also deal with scheduling, but the partial-update framing is specific enough to identify the 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?

Usage is implied by the list of editable fields, so an agent can infer this is for partial edits rather than creation, listing, or deletion. However, there is no explicit guidance on when to use this versus reschedule_post, schedule_post, or update_comment, and no when-not-to-use or prerequisite information.

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, destructiveHint=false, openWorldHint=true, so the safety profile is partially covered. The description adds no key behavioral facts for a mutation: whether accountIds replaces the full membership list or appends to it, whether omitted fields are left untouched, or what happens to accounts dropped from the array. 'Reassign its accounts' hints at a full-set replacement without confirming it.

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

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

A single short sentence with no filler, and the primary operation is front-loaded. It is arguably too terse rather than padded, but it wastes nothing.

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 six-parameter mutation with no output schema and zero parameter documentation in the schema, the description leaves too much open: partial-update semantics, membership replacement behavior, null-clearing, and the return shape are all absent. An agent could invoke it but could easily clobber a team's account list unintentionally.

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% across six parameters, so the description must compensate and largely does not. It implies name, description, and accountIds only, leaving slug and avatarUrl unmentioned, and gives no guidance on the replace-vs-merge semantics of accountIds or on how to clear the nullable description/avatarUrl fields.

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 specific verbs (rename/re-describe, reassign) against a specific resource (team), which is far more informative than the tautological title. It does not differentiate itself from the adjacent account-membership siblings (add_team_account, remove_team_account), which is the most likely source of confusion.

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

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

Usage is implied: you call this to change an existing team's name, description, or account set. There is no explicit when/when-not, no mention of what requires a team to already exist, and no routing statement against add_team_account/remove_team_account for account membership changes.

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 a non-read-only, open-world, non-destructive write, and the description is consistent with that, adding that remote URLs must be public and that local paths are read. However, with zero required parameters it never clarifies whether url and path are mutually exclusive or whether at least one must be supplied, nor does it mention size/format limits or failure behavior for an open-world upload.

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

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

Two tight sentences: the first front-loads the action and its input modes, the second explains the return value and downstream linkage. Nothing is redundant with the title or 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?

It covers the return value in lieu of an output schema, which is valuable, but for an open-world write tool with no required parameters and 67% schema coverage, the missing guidance on url/path exclusivity and upload constraints leaves real gaps an agent would hit.

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 67% (mediaType has an enum but no description), and the description compensates by spelling out that paths cover image/video/PDF, which maps onto the image/video/document enum. The 'or' phrasing also implies the url-path split, though mutual exclusivity is left implicit.

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 (upload media) plus the two input modes (public URL, local file) and the return shape (a media row whose id posts reference via mediaIds). The action is unambiguous and clearly distinct from sibling read/delete tools like get_media, list_media, and delete_media, though it doesn't call those out 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?

The description makes the usage context clear: this is how you get a media id into the system so it can be referenced in posts via mediaIds, which is the real trigger for calling it. It stops short of stating exclusions (e.g. use get_media/list_media for existing assets) or prerequisites, so it isn't a full when/when-not guide.

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