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

Annotations already declare it is a non-readOnly, idempotent, non-destructive, non-open-world write. The description adds the state transition (waiting -> scheduled) and an authorization constraint that the account owner must have requested it, which the annotations do not convey.

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

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

Two short clauses, front-loaded with the action and effect, 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 single-parameter tool with full annotation coverage and a well-documented param, the description covers purpose, effect, and authorization. Only minor edge-case behavior (e.g., what happens if the post is not awaiting approval) is left implicit.

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 id parameter is already documented with its source ('from list_scheduled_posts'). The description adds no parameter-level detail, so the baseline 3 applies.

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

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

States a specific verb (approve), the resource (a post), and the precondition plus outcome ('waiting for approval, so it is scheduled'). This distinguishes it from schedule_post, publish_post_now, and resume_post without needing 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?

Explicitly gates usage: 'Only do this when the account owner has asked you to.' That is clear when-to-use guidance, though it does not name alternative tools for other approval/scheduling paths.

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

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

Annotations already declare this a non-read-only, non-destructive, non-idempotent mutation; the description adds the key behavioral fact that the draft stays inert until schedule_draft runs, which is exactly the lifecycle context an agent needs. It omits that repeat calls create duplicate drafts (relevant given idempotentHint=false), so not a 5.

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

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

Three short sentences, zero filler, with the most important constraint (not posted until scheduled) placed early. Nothing wastes space.

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 say what comes back (presumably a draft id needed for schedule_draft) and confirm that content is the minimum required to create one. For a 19-param create tool that omits any mention of its return value, the definition is adequate but 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 100%, so all 19 parameters including the nested 'options' object and platform-specific fields are already documented in the schema. The description mentions no parameter at all, so baseline 3 is appropriate.

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

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

States a specific verb and resource ('Save a post as a draft') and immediately draws the boundary against the sibling that actually publishes it, schedule_draft. An agent can tell what this does and what it does not do without opening the schema.

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

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

Gives a clear use condition ('without choosing an account or a time yet', 'a plan a human will finish') and names the follow-up tool schedule_draft. It stops short of an explicit when-not-to-use rule (e.g. 'if you already have an account and time, use schedule_post'), so 4 rather than 5.

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

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive, closed-world write. The description adds real value beyond that: the client needs no account, the link is delivered at a lazyrelay.com/review/<token> URL, and a plan must include review links. It doesn't clarify whether links can be regenerated or what happens on re-invocation.

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

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

Two sentences, front-loaded with the core action and the client workflow. The URL format and plan requirement are secondary but relevant. Minimal waste, though slightly dense in the second 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 creation tool with no output schema, the description covers the outcome (a shareable review link at a concrete URL) and the plan prerequisite. Enough for an agent to call it correctly, though it omits whether the token is returned in the response versus only referenced.

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 label, brandLabel and expiresInDays are already documented in the schema. The description adds no extra syntax or format detail for these parameters, so the baseline 3 applies.

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

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

States a specific verb 'Create' and resource 'review link', then spells out the exact client-facing workflow (view, approve, request changes, comment) with no account needed. An agent can distinguish it from list_review_links and revoke_review_link without opening any schema.

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

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

The description implies the use case (send a client a link to review pending posts) and gives a prerequisite ('Needs a plan that includes review links'), but never names when to prefer this over alternatives or states exclusions. Usage is inferable rather than explicit.

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

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

Goes well beyond the annotations (destructiveHint, idempotentHint): it discloses that deleting a published post only removes LazyRelay's record while the post stays live on the platform, and that a post mid-publish cannot be deleted and should be retried. This is exactly the kind of consequence-level context annotations cannot convey.

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

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

Four sentences, each earning its place: purpose, primary use, published-post caveat, and the in-flight failure mode. The main use case is front-loaded 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 a one-parameter destructive tool with no output schema and annotations covering the safety profile, the description supplies all needed context: what gets deleted, when it silently doesn't, and the retry case.

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

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

Schema coverage is 100% for the single 'id' parameter and the schema already documents its origin ('from list_scheduled_posts'). The description adds no syntax or format detail beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource ('Delete a post from LazyRelay') and immediately frames the primary use case (cancel a pending/waiting-for-approval post), which distinguishes it from siblings like pause_post or update_post. An agent can identify the operation 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?

Explicitly says when to use it ('cancel a pending or waiting-for-approval post before it goes out') and covers the edge case of an already-published post. It does not, however, compare itself to alternatives such as pause_post or reschedule_post, so an agent must infer when deletion beats pausing.

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, idempotentHint and destructiveHint=false, so safety is covered. The description adds value beyond them by enumerating the returned metrics and noting that availableTags reveals the tags in use, which is genuinely useful discovery context. It stops short of covering pagination or the effect of combining brand and tag filters.

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 with no filler; the metric list is front-loaded and the filtering hint follows. Slightly dense, but every clause conveys information an agent can act on.

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 helpfully sketches the return content (counts, rates, breakdown, totals), and annotations carry the safety profile. What remains thin is the time window semantics — 'recent window' leans on the schema's default of 30 days — but overall it is complete enough to call correctly.

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

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

Schema description coverage is 100%, so all three parameters (tag, days, brand) are already documented in the schema, establishing the baseline of 3. The description's 'filter by brand or by a tag' and 'recent window' framing loosely maps to these params but adds no syntax, format, or interaction detail beyond the schema.

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

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

The description names the resource (analytics summary) and enumerates the concrete measures returned: post counts, verified-live rate, per-platform breakdown, engagement totals. That is far more specific than a tautology and lets an agent know exactly what this tool yields, though it does not need to distinguish itself from a competing analytics sibling because none exists.

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

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

It states two filtering modes (by brand, or by tag to compare campaigns) and points at availableTags as the source of tag values, which implies usage. However, it never says when to prefer this tool over raw post listings like list_scheduled_posts, nor does it set any exclusions or preconditions.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive behavior, but the description adds substantial operational context: background-refreshed stored copy rather than live calls, resilience to platform outages, 30-day comment retention, per-minute rate-limit cost, dashboard notification marking, and an explicit prompt-injection warning about comment text.

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

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

The description is long but well structured and front-loaded: it starts with purpose, then provides RESPONSE, BEHAVIOUR, EDGE CASES and USAGE sections. With no output schema, each section earns its place by clarifying return shape, side effects, and limits.

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 zero input parameters, no output schema, and a read-only annotation set, the description is complete. It documents the JSON response object, triage semantics, empty-result cases, unsupported-platform behavior, polling/rate-limit constraints, and untrusted-content handling.

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 input parameters, so the baseline is 4. The description appropriately shifts detail to the response shape rather than input semantics, and there are no parameters whose meaning needs additional explanation.

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 ('Reads') and resource ('recent comments') with clear scope: this account's own newest posts, up to the 15 newest confirmed live posts. It also distinguishes the tool from live platform reads by explaining that it uses LazyRelay's stored copy and names supported platforms.

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

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

Gives clear intended use ('find sales questions, unhappy customers and plain questions that need an answer') and when-not guidance: polling faster than every few minutes returns nothing new, and replying is not available through MCP. It does not explicitly name an alternative sibling tool, though no close sibling exists in the provided list.

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

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

Annotations already cover readOnly, idempotent and non-destructive, so the bar is lower; the description still adds real context by disclosing the data source (Settings posting times), the return type (ISO timestamp), and the empty-state behavior ('Says so plainly if no posting times are saved'). It does not describe the shape of that no-slots response or any timezone/rate-limit nuance.

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 what the tool returns, followed by the return format and the edge case. Nothing is redundant or 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 output schema, the description carries the return-value burden and does so (ISO timestamp for scheduledFor) plus the no-posting-times case. For a single-parameter read tool with full annotation coverage, nothing an agent needs to call it correctly is missing.

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

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

Schema coverage is 100% and the single parameter is already documented in-schema with a pointer to list_connected_accounts. The description only restates 'one connected account' without adding format, scoping, or validation detail, so the baseline 3 applies.

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

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

States a specific verb and resource ('the account's next free posting time for one connected account') and scopes the source of truth ('from the posting times saved in Settings'). This is clearly distinguishable from sibling list_posting_slots, which enumerates slots rather than resolving the single next free one.

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 embeds the intended use case by naming the consumer field ('Returns an ISO timestamp to use as scheduledFor'), which effectively routes the agent to call this before schedule_post/schedule_draft. It stops short of naming an explicit alternative or a when-not condition, so it is clear context without exclusions.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world). The description goes further by enumerating what data the agent will actually receive, including concrete examples of required fields per platform, which is real added context.

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

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

The content-rich clause is front-loaded and the usage instruction trails it, which is the right order. It is list-heavy but each enumerated category (limits, media rules, required fields, features) 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?

With no output schema, the description carries the burden of describing returns, and it does so at a useful level of abstraction with concrete examples. Nothing critical about calling the tool correctly is missing.

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

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

Schema description coverage is 100% and the single optional param is fully documented there. The description repeats the 'leave it out for all platforms' semantics and adds example values, but contributes nothing beyond the schema.

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

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

The description names a specific resource and its contents: platform posting constraints (text limits, media rules, required fields, features). It is unmistakably distinct from every sibling, none of which returns platform policy data.

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 framing 'What a platform accepts BEFORE you post' establishes when this is useful (pre-flight validation against a channel), and the closing sentence explains how to scope the lookup. It stops short of explicitly contrasting with siblings, though no sibling overlaps.

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, idempotentHint=true, openWorldHint=false, so the safety profile is covered. The description adds real content-level value by specifying what the read returns (client statements, change requests, replies), but says nothing about ordering, pagination, or behavior when no feedback 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?

One sentence, zero filler, and the post-scoping qualifier is front-loaded before the enumerated contents. It is a sentence fragment rather than a full statement, which is a minor structural blemish but not wasteful.

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 describing the return value and does so adequately by listing the kinds of feedback content returned. For a single-parameter read-only tool with full annotation coverage, an agent has enough to call it correctly; only edge-case behavior is missing.

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

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

Schema description coverage is 100% and the single 'id' parameter is documented in the schema as coming from list_scheduled_posts. The description adds no further semantics about the identifier, so the baseline 3 applies — the schema does all the work.

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 — the feedback conversation attached to a post awaiting approval — and enumerates its contents (client comments, change requests, replies). That is far more concrete than a tautology, though it uses a noun phrase rather than an explicit verb and never distinguishes itself from adjacent siblings like get_mentions or reply_to_post_feedback.

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 'on a post waiting for approval' implicitly scopes usage to the review/approval workflow, which is useful context. However, there is no explicit when-to-use statement, no prerequisites, and no mention of the obvious companion tool reply_to_post_feedback for responding to the feedback this tool retrieves.

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 cover the safety profile (readOnly, non-destructive, idempotent, closed-world). The description adds two behavioral constraints not in annotations: post must be confirmed live, and the API key needs sharing permission. It doesn't explain what the link looks like or its expiration, which would be useful.

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 purpose and followed by preconditions. No wasted words.

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 annotations covering safety and a fully described single parameter, the description adds the two key preconditions needed to call it correctly. It could mention the sibling create_review_link and any output caveats, but overall it's sufficient for a simple read operation.

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

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

Schema coverage is 100% and the parameter description already tells the agent where to get the id ('from list_scheduled_posts'). The main description adds no parameter details beyond this, 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+resource: generates a public proof-of-publish link. It describes the artifact's purpose ('shows a post was really confirmed live, to share with a client'). However, it doesn't name or distinguish from sibling create_review_link, which appears closely related.

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 condition for use ('only works for a post confirmed live') and the permission requirement ('API key must be allowed to share proof'). It doesn't explicitly name alternatives like create_review_link, but the preconditions are clearly 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 declare readOnlyHint, idempotentHint, and openWorldHint, so the safety and freshness profile is already covered. The description adds the important cross-tool dependency that tiktokPrivacyLevel is required for posting and must come from this call, which is behaviorally useful context beyond the annotations.

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

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

Two sentences, front-loaded with what is returned and followed by the precise reason to call it. No filler or repetition.

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

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

For a single-parameter read tool with no output schema, the description is largely complete: it lists the returned fields and the downstream requirement. It could mention the return shape more explicitly, but the annotations and schema already carry most of the burden.

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

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

Schema coverage is 100% and the single parameter socialAccountId is fully documented as coming from list_connected_accounts. The description does not add syntax or format details beyond the schema, so baseline 3 is appropriate.

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

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

States a specific verb and resource: retrieve the privacy levels, comment/duet/stitch allowances, and max video length for one connected TikTok account. It is clearly distinguished from siblings like list_connected_accounts, which provides account ids rather than per-account posting capabilities.

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

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

The description gives explicit when-to-use guidance: 'Call this before posting to TikTok, because tiktokPrivacyLevel is required and must be one of the levels returned.' It ties the dependency to a concrete follow-up action, which is exactly what an agent needs for sequencing.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, closed-world), so the bar is lower. The description still adds real behavioral context the annotations lack: the connection state signal ('Accounts that need reconnecting say so') tells the agent the read can surface actionable auth problems.

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 resource scope is front-loaded and the reconnect caveat is appended only after the core payload is stated. No filler or restated annotation boilerplate.

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

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

With no output schema and no parameters, the description carries the burden of describing returns, and it does name platform, display name, the id, and the reconnect flag. It stops short of ordering, pagination, or what an empty list means, but for a zero-arg read tool this is close to sufficient.

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. The description correctly omits parameter discussion and instead spends its words on output contents, which is the right allocation.

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 ('List') plus a precisely scoped resource ('every social account connected to this LazyRelay account'), with the returned fields named. It is clearly distinct from siblings like list_workspaces, list_pinterest_boards and the posting tools it feeds, so an agent can route to it without opening a 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?

There is no explicit when-to-use / when-not statement or named alternative. The phrase 'the id the posting tools need' implies this is a prerequisite lookup before scheduling/publishing, but the agent must infer that ordering and there is no guidance on duplicates or empty results.

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, idempotentHint, non-destructive and open-world, so safety behavior is covered. The description adds the per-account scoping constraint but says nothing about pagination, result size, or behavior when the account has no boards — a modest addition over the annotations.

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

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

Two short sentences with zero filler: the first defines the output, the second justifies the call. The most decision-relevant fact (you get boardIds) is front-loaded.

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

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

For a one-parameter, read-only list tool with no output schema, the description covers what is returned (boards and their ids) and the prerequisite account id. It omits result volume/pagination expectations, which is a minor gap for a simple listing 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 100% and the single parameter is already documented as an id from list_connected_accounts. The description reinforces the one-account-per-call nature of the parameter but adds no format or validity detail beyond the schema, so the baseline 3 applies.

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

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

The description names the resource (Pinterest boards with their ids) and the scope (one connected Pinterest account), which is enough to distinguish it from every sibling — no other tool lists boards. The verb is only implied ("its boards"), so it falls just short of an explicit verb+resource statement.

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?

"A Pinterest post needs a boardId from this list" tells the agent exactly why and when to call it, and the schema links the upstream prerequisite (list_connected_accounts). It stops short of naming an explicit alternative or exclusion, but there is no competing sibling to route away from.

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, idempotentHint, and destructiveHint=false, so the safety profile is fully carried by structured data. The description adds only that these are Settings-saved values (implicitly static config, not live-computed), but says nothing about return format, ordering, or pagination.

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 parenthetical sentence with no filler and the key content (days, time, time zone) front-loaded. It is efficient, though arguably terse to the point of under-specification.

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 partially sketch the return shape (days, time, time zone), which is useful. However, for a read tool whose sibling get_next_free_slot overlaps in topic, it lacks the routing and return-format detail needed to be fully self-sufficient.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate on the input side.

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 is a noun fragment ('The posting times saved in Settings') rather than a verb+resource statement; the agent leans on the tool name to infer that it lists slots. It also doesn't distinguish this from the closely related sibling get_next_free_slot, which returns computed availability rather than saved configuration.

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 and no mention of alternatives, despite get_next_free_slot being an obvious near-neighbor an agent could confuse this with. The phrase 'saved in Settings' hints at context but does not tell the agent when to pick this tool.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the response includes each link's status and the plan's allowed count, which is useful context, but says nothing about pagination, ordering, or auth requirements for a read 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 compact sentence with no filler. It is slightly weakened by being a noun phrase rather than a front-loaded action statement, but nothing in it 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?

With no output schema, the description carries the burden of return-value disclosure, and it does name two returned fields (status and plan allowance). It is adequate for a zero-argument read tool, but an agent still lacks a full picture of the returned 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?

The input schema is empty (0 parameters, 100% coverage of nothing), so there is no parameter semantics to explain and no gap for the description to fill. Baseline of 4 applies to a no-argument tool.

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

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

The description names the specific resource (the account's client review links) and what it surfaces (status and plan allowance), which cleanly separates it from the create_review_link, revoke_review_link, and get_post_feedback siblings. However, the listing action itself is only implied by the tool name rather than stated as a verb in the description.

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 named alternative. An agent must infer from the name alone that this is the read path for review links, and the description never says when it should be preferred over sibling tools.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description still adds genuine non-obvious context: the meaning of the returned total (post-filter, post-limit, not a global count) and the summary-vs-detail behavior, which an agent could otherwise misread.

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

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

Front-loaded with what is returned and to whom, then progressively adds detail on the detail flag, filtering, and the total caveat. Slightly dense in the enumeration of statuses, which the schema enum already carries, but no wasted sentences.

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 correctly carries the return-value burden by explaining the summary/detail distinction and the total-field semantics. For a 4-param, zero-required list tool this is nearly complete; only pagination/ordering behavior beyond limit is unstated.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining that the limit interacts with the reported total and that detail=true upgrades records to full form. It reinforces the status/account filtering rather than merely restating it.

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

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

States a specific verb and resource ('This account's upcoming and recent posts') and names its scope precisely, including the status values and the 'confirmed live' dimension. An agent can tell this is the read/list view of scheduled posts apart from siblings like schedule_post or create_draft.

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 practical advice ('Filter by status or account to keep it small') but never states when to prefer this over alternatives such as get_analytics_summary or list_posting_slots, nor any exclusions. Usage is implied by the list verb rather than 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 fully cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint=false), so the description is not obligated to restate them. It does add useful domain context about what the snippets actually are and that one is designated the signature, but says nothing about ordering, return shape, or whether snippets are account-scoped vs workspace-scoped.

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 no filler, front-loaded with the resource and followed by clarifying examples. Every clause earns its place and nothing is repeated from the annotations.

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 must convey the return content, and it does: snippets, their kinds (hashtag groups, sign-offs), and the signature designation. Only the exact field structure and snippet count limits are left unstated, which is a minor gap for a zero-parameter listing tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; per the baseline rule, a 4 applies. The description correctly implies no filtering or selection input is needed.

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 precisely ('saved text snippets') and illustrates it with concrete examples ('hashtag groups, sign-offs'), plus an extra distinguishing detail (which snippet is the signature). The listing verb is only implied rather than stated, but no sibling tool covers snippets, so an agent can identify this without ambiguity.

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

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

The trailing phrase 'to paste into a post' hints at the use case (retrieving reusable content for composing posts), but there is no explicit when-to-use statement, no prerequisites, and no guidance on how this relates to sibling tools like create_draft or schedule_post. Usage is implied, not 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, idempotentHint=true, so the safety profile is covered. The description adds value by clarifying what a workspace is and the meaning of the returned id, but says nothing about rate limits, pagination, or the shape of the listing beyond the id.

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

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

A single tight sentence with no filler, front-loading the action and immediately resolving the brand/workspace naming ambiguity. Every clause 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 zero-parameter, read-only list tool with no output schema, the description covers what is returned at a high level (workspaces plus their id). It could note other returned fields or ordering, but nothing critical to making the call is missing.

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

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

The tool takes zero parameters, so there is nothing to document; the baseline for a parameterless tool is 4. The description correctly implies no filtering input is required.

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 (List) and resource (brands/workspaces) scoped to 'this account', and disambiguates the terminology by equating brands with workspaces. It does not explicitly contrast with sibling list tools such as list_connected_accounts, but the resource is concrete enough for an agent to select 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?

Usage is only implied: the phrase 'the id needed to file a post under a specific one' hints that this should be called before scheduling/publishing into a workspace. There is no explicit when-to-use statement and no named alternative or exclusion, so the agent must infer the step in the workflow.

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 safety profile (not read-only, idempotent, non-destructive, closed-world), so the description only needs to add context. It clarifies the observable effect on scheduling but says nothing about resulting post state, whether a paused post still occupies its slot, or how pause interacts with approval flows.

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 effect first, the reversal path second. No filler, no restatement of the name or annotations.

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

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

For a single-parameter state-change tool with no output schema and annotations covering idempotency and safety, the description is nearly sufficient: it explains what changes and how to undo it. It could go slightly further on what state the post lands in, but nothing essential to calling it is missing.

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

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

Only one parameter, fully documented in the schema (100% coverage) including its provenance ('from list_scheduled_posts'). The description adds no further detail about the id, so the schema does all the semantic work — the baseline 3 for high-coverage schemas 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 (hold/pause) and resource (a pending post) plus the effect: preventing it from going out at its scheduled time. It also names the sibling that reverses it, so an agent can distinguish pause_post from resume_post without reading 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?

The phrase 'pending post' scopes usage and the description explicitly routes to resume_post for the inverse action. It does not state exclusions (e.g., what to do with a post already published), but the context is clear enough to select the tool correctly.

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

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

Annotations already declare write, non-idempotent, open-world, non-destructive, but the description discloses the genuinely non-obvious behavior that delivery is asynchronous via the scheduler and not synchronous, plus how to verify it went live. This is high-value context beyond the annotations, though it says nothing about rate limits or failure/retry 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?

Three sentences, front-loaded with the action and its timing caveat, with no filler. Slightly clunky phrasing in the middle sentence ('it is not published synchronously') and the trailing field-parity note are minor deductions.

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 20-parameter, nested-object, no-output-schema tool, the description covers the critical operational risk (async delivery) and routes the agent to list_scheduled_posts/verifiedLive to confirm success, which substitutes for a return-value contract. The heavy platform-specific parameter space is fully handled by the schema.

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

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

Schema description coverage is 100%, so all 20 parameters including the nested platform-specific 'options' object are already documented. 'Same fields as schedule_post' adds a useful parity signal but no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('Publish to one connected account right away') and immediately scopes it against the sibling operation by contrasting with 'instead of scheduling'. An agent can distinguish this from 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?

Explicitly frames this as the alternative to scheduling and gives a concrete follow-up procedure ('call list_scheduled_posts afterwards and check verifiedLive'). It does not spell out when NOT to use it (e.g. for drafts or reviewing before publish), which keeps it short of a 5.

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

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

Annotations already provide the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), so the description's burden is lower. However, it adds only that the client sees the reply on their review page, without explaining rate limits, character limits beyond the schema, or any side effects. For a write operation, more behavioral context would be beneficial.

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

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

The description is a single, well-structured sentence that front-loads the action and includes a useful secondary detail. It is concise and every part earns its place.

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

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

Given the tool's relative simplicity (2 params, full schema coverage, annotations) the description covers the basics. However, as a mutation tool it could include more context about permissions, the effect on the post, or return behavior, making it only minimally sufficient.

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

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

Schema description coverage is 100%, so the schema fully documents both parameters. The description adds no parameter-specific information, so the baseline score of 3 is appropriate.

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

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

The description states a clear verb (Add a reply) and resource (client conversation on a post), making the tool's action unambiguous. It doesn't explicitly differentiate from siblings like get_post_feedback, but the 'reply' noun and the fact that it's an addition rather than a retrieval sets it apart adequately.

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

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

No guidance is given about when to use this tool versus alternatives such as get_post_feedback or other communication tools. The description implies usage from its purpose but provides no explicit conditions, 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 cover safety (readOnlyHint=false, idempotentHint=true, destructiveHint=false), and the description adds two things they don't: that platform rules for the new time are re-validated, and that passing the current time triggers immediate publishing. The immediate-publish side effect is genuinely useful behavioral disclosure.

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, and the core action is front-loaded before the two behavioral notes. Every sentence carries information the agent needs.

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

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

For a 2-parameter mutation with full schema coverage, annotations, and no output schema, the description covers the action, the immediate-publish case, and re-validation. It stops short of saying what happens when the rules check fails or that only pending (not published/failed) posts qualify.

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

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

Schema description coverage is 100%, so the schema already documents both parameters, giving a baseline of 3. The description adds only the semantic that scheduledFor equal to now means publish-now, which is a small but real addition beyond the schema text.

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 ("Move a pending post to a new time") and constrains the target to pending posts, which separates it from update_post and schedule_post. It does not name siblings explicitly, but the note about passing the current time implicitly handles the overlap with publish_post_now.

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 post" implies the eligible state and the current-time note gives one concrete usage pattern, but there is no explicit when-not guidance or named alternative (e.g. publish_post_now for immediate publishing, update_post for non-time edits). 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 (readOnlyHint=false, idempotentHint=true, destructiveHint=false) already establish the mutation and safety profile, so the description clears the lower bar. It adds genuine behavioral detail the annotations do not: a past-due paused post is published immediately rather than waiting for a future slot.

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, no filler, with the core action stated first and the timing nuance immediately after. Every sentence earns its place.

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

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

For a one-parameter mutation with annotations covering the safety profile and no output schema, the definition supplies enough to call it correctly and tells the agent the key timing behavior. It stops short of describing error cases, such as resuming a post that was never paused.

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 a single parameter with 100% schema description coverage ('The post id, from list_scheduled_posts'), so the schema already carries the semantics and cross-tool sourcing. The description adds nothing about the id, matching the baseline 3 for high-coverage schemas.

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

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

The description states a specific verb+resource ('Let a paused post go out again'), clearly framing the inverse of the sibling pause_post. It does not name the sibling explicitly, but the 'paused post' scoping makes the operation 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?

Usage is implied by the word 'paused' — an agent can infer this applies only to posts previously paused via pause_post. There is no explicit when-to-use statement, no mention of what happens when called on a non-paused post, and no named alternative.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, covering the safety profile. The description adds the behavioral detail that revocation takes effect 'at once', which is useful immediacy context beyond the annotations, though it doesn't describe permissions, side effects, or reversibility.

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 wasted words. It efficiently communicates the essential action and timing.

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

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

Given the simple, single-parameter mutation with annotations covering safety traits and no output schema, the description is nearly sufficient. It could mention whether the link can be restored or what happens to existing feedback, but the core behavior is clear.

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

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

Schema description coverage is 100%, and the schema already documents the single 'id' parameter with a pointer to list_review_links. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb ('Stop ... working') and resource ('client review link'), clearly distinguishing this tool from create_review_link and list_review_links by virtue of the destructive action. An agent can immediately understand the tool's purpose without opening the schema.

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

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

The description offers no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. It merely states what the tool does, leaving the agent to infer the appropriate context.

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

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

Annotations already declare readOnly=false, destructive=false, idempotent=false and openWorld=true, so the safety load is carried. The description usefully adds that platform rules are validated at schedule time and that failures are actionable, which is real behavioral context the annotations do not provide.

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

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

Two tight sentences, front-loading the core transformation before the validation caveat. Efficient, though the second sentence is somewhat soft and could name the alternative tool instead.

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 23-parameter tool with a nested options object and no output schema, the description covers the core action and error model but says nothing about how the many platform-specific fields interact or what success looks like. The 96% schema coverage compensates for most of the gap, leaving the description 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 description coverage is 96%, so nearly every parameter is already documented in the schema. The description only loosely maps to two of them ('account' and 'time') and adds no format or constraint detail beyond what the schema provides, matching the baseline for high 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 and resource: converting a draft into a real scheduled post, which clearly differs from create_draft and schedule_post. However, it never names the sibling it is distinct from, so the agent must infer the draft-vs-new distinction from the name alone.

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

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

It implies usage through 'choosing the account and the time' and frames errors as fixable, which orients the agent, but it gives no explicit when-to-use versus schedule_post or publish_post_now, and no prerequisites beyond the passing mention of platform rules.

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, idempotentHint=false, openWorldHint=true). The description usefully adds that requiresApproval holds the post for client approval and that each call posts to one account, but it never warns that repeat calls are non-idempotent (duplicate posts) or what happens on platform-rule violations, which the non-idempotent, open-world annotation makes relevant.

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

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

Three tight sentences, front-loaded with the single-account scoping rule and then the platform prerequisites. No filler or restated 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?

For a 22-parameter, nested-object, no-output-schema mutation tool, the description covers the high-risk gotchas (platform-specific required fields, approval hold, one-account-per-call) and delegates rest to get_platform_rules. It leaves the non-idempotency/duplicate-call risk unstated, which is the main 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 coverage is 100%, so the baseline is 3; each parameter is already described in the schema. The description reinforces the TikTok/Pinterest requirements and the requiresApproval meaning but adds no syntax or format detail beyond the schema.

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

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

States a specific verb (schedule) and resource (post) with an explicit scope constraint: ONE connected account per call, call once per account for multiple. This clearly separates it from publish_post_now and create_draft/schedule_draft siblings.

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

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

Gives concrete prerequisites and routing: list_connected_accounts for the id, get_platform_rules for platform needs, and names the two platform-specific requirements (tiktokPrivacyLevel, boardId). It does not explicitly contrast with publish_post_now or created/scheduled drafts, so it stops short of full alternative routing.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, so safety is covered. The description adds the lifecycle eligibility constraint (edits blocked once posting or done), which is real behavioral context not present in the annotations. It stops short of clarifying whether unlisted fields are preserved or cleared on an update, which matters for a 20-param edit.

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: eligibility first, then the alternative. No filler, and the routing hint is placed at the end where it is easy to act on.

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 20 parameters, full schema coverage, and no output schema, the description covers what the schema cannot: lifecycle eligibility and the reschedule alternative. The remaining gap is update semantics (partial merge vs. full replace of unlisted fields), which an agent editing a complex post would want.

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 every parameter already carries its own documentation (platform scoping, defaults, TikTok requirements). The description only echoes the parameter families ('text, media, tags, options') without adding syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb (edit) plus the resource and the exact lifecycle states it applies to (draft, awaiting approval, still-pending), and names the sibling reschedule_post as the tool for a different operation. An agent can separate this from reschedule_post and approve_post without opening a 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 both the when (draft / waiting-for-approval / pending) and the when-not (once posting or done), plus the explicit alternative for changing time. Nothing about routing is left to inference.

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