LivePublicator

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

Annotations already declare the safety profile (not read-only, not destructive, idempotent). The description adds real behavior nowhere in the structured fields: with no image supplied the call returns a one-time upload link, and it explains downstream rendering thresholds (1200 px, 600 px, under 600 px fallback to a logo cover).

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?

Purpose is front-loaded in the first sentence, then input options, then a one-line sizing/fallback rule. Every sentence carries information, though the sizing detail is the least essential and the block runs slightly long.

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 covers the non-obvious return case (one-time upload link) and the optionality of the call. Combined with annotations that cover mutation safety, an agent has enough to invoke this correctly; the draft-release-only constraint could be stated more explicitly.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description goes beyond the per-field schema text by spelling out the branching logic between image_url, image_file, and the neither-case. image_is_ai is left to its schema description, which is adequate.

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 opening sentence names a specific verb and resource ("Adds a cover image") plus the scope ("a draft press release"), which separates it from create_release/update_release/publish_release. It doesn't explicitly name a sibling to route against, so it falls just short of the top tier.

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 concrete usage context: pass an image_url, pass a chat-attached file, or pass neither to get a one-time upload link, and it explicitly states the step is optional. No explicit when-not-to-use or named alternative tool, but the conditions are clear.

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

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

Beyond the annotations it discloses that LivePublicator will not rewrite the text, that the response is either a full list of problems to fix or a private preview plus edit link, that it consumes no credit and does not publish, and that company/press contact/spokesperson default from the account when omitted. These are exactly the behavioral facts an agent needs and that the annotations cannot express.

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 with purpose and validation behavior, and the trigger examples are tightly packed. It runs long as a single paragraph and folds some per-parameter guidance into prose that overlaps the schema, but no sentence is pure filler.

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

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

With 19 parameters, no output schema and a non-idempotent write, the description still covers defaults, image handling, agency authorization, validation feedback and the return shape. An agent has enough to call it correctly without opening 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 coverage is 100%, so the baseline is 3; the description adds real value on top by explaining the account-supplied defaults for company_name/contact fields, the distinction between image_url and image_file (chat attachment), the purpose of image_is_ai, and the agency-only client_authorized flag.

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 opening sentence gives a specific verb and resource (saves a press release as a draft) plus the side effect (checks length, structure, links, image). It explicitly excludes publishing, which separates it from publish_release, and the draft/check framing separates it from update_release and preview_press_release.

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 concrete when-to-use triggers (product launch, feature, partnership, funding, or news just written in a blog post in chat) and instructs the agent to draft the whole release itself. There is no explicit when-not or named sibling routing, but 'It does not publish' implicitly steers to publish_release for that step.

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

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

Adds real behavior beyond the annotations: the link is preserved, the prior version is retained (reversibility), and the edit is re-checked before it appears (a review delay the agent should expect). It does not say what the tool returns, whether re-review can reject the change, or what error surfaces once the 24-hour window closes — meaningful gaps for a destructiveHint mutation on live 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?

Four short sentences, zero waste: purpose and time window first, then the partial-update instruction, then the consequences (same link, prior version kept, re-check). Nothing is buried or repeated from the schema.

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

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

For a 13-parameter mutation with full schema coverage and rich annotations, the description covers scope, input contract and side effects adequately. With no output schema, it never indicates what a successful call returns or how a rejection after re-review is reported, which is the main remaining hole.

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 field descriptions already carry word counts, character limits and link caps, so the baseline is 3. The description earns an extra point by stating 'Send only the fields to change,' which makes the partial-update contract explicit — the only required field being release_id implies this but does not state 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?

Names a specific verb and resource — fixing the text of an already-published press release — and pins the scope with 'within 24 hours of it going live.' The examples ('a typo, a wrong date, a link, the quote') make it immediately distinguishable from create_release, publish_release and update_release without opening any schema.

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

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

Gives a clear use window (within 24 hours of going live) and an explicit exclusion ('After 24 hours the text can't be changed'), plus the partial-update instruction 'Send only the fields to change.' It stops short of naming the alternative tool an agent should use for a release older than 24 hours, leaving that routing to inference from the sibling 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it discloses what the payload contains (credits, missing fields, human-approval vs auto-publish mode) and the cross-tool dependency that create_release populates the press contact. It does not mention pagination or caching, but for a zero-arg read there is little else to disclose.

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 whose opening clause ('Shows the signed-in LivePublicator account') establishes purpose immediately, followed by an enumerated payload list where each clause earns its place. It is dense and comma-heavy, reading as a run-on, but nothing is 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?

There is no output schema, so the description carries the burden of describing return values, and it does so field by field. Combined with the 'call once before drafting' timing rule and the create_release dependency note, an agent has everything needed to call it correctly and to interpret the result.

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 no parameters, so per the rubric the baseline is 4. The description correctly adds no parameter information, and instead spends its words on return semantics, which is the right trade-off 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?

States a specific verb and resource ('Shows the signed-in LivePublicator account') and then enumerates the exact contents returned: company, saved press contact and spokesperson, missing items, credits, release-approval mode, and agency client companies. No sibling tool reads account state, so it is trivially distinguishable from create_release, list_releases, etc.

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 directive with a condition: 'Call it once before drafting,' which ties invocation to the drafting workflow that the sibling create_release belongs to. It also warns 'do not ask the user for them' because create_release fills the contact fields. It stops short of naming when not to call it or an alternative source for the same data.

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 closed-world, so the safety profile is covered. The description adds value annotations cannot: the set of status values the tool reports and the fact that a live link is returned once published — meaningful return-shape disclosure given there is no output schema.

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

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

Three short sentences, front-loaded with what the tool reports, then when to use it, then when not to. No filler and nothing repeated from the title 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?

With no output schema, the description correctly takes on the burden of describing return values (statuses plus live link) and the usage context, which is enough for a single-parameter read. It stops short of covering failure behavior for an invalid or missing release_id.

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 required parameter and schema description coverage is 100% ('The release id.'), so the schema already carries the parameter's meaning. The description adds nothing about id format, where to obtain the id, or behavior when the id is unknown — 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 ('shows where') and resource ('a press release') and enumerates the concrete states it resolves to: draft, waiting for a person to check it, scheduled, or live. It also names what else comes back (the live link), which lets an agent distinguish this from list_releases or update_release 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 an explicit usage condition ('Only when the user asks about a release later') plus two named exclusions (create_release, publish_release, whose answers already include this). Strong routing guidance, though it doesn't address list_releases, the other sibling an agent might reach for when the user wants release data.

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), so the bar is lower. The description still adds value by disclosing what the result contains (status and links) and that results are scoped to the caller's own account, which matters given no output schema 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?

Three compact sentences, zero filler, with the core action stated first and the usage constraint immediately after. Nothing is repeated from 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?

For a single-parameter read tool with full schema coverage, the description covers purpose, trigger, exclusion, and return content. Without an output schema the return description ('status and links') is doing real work, though pagination/ordering beyond newest-first is not mentioned.

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 optional parameter and schema coverage is 100% — the schema already documents 'limit' including the default of 10 and the newest-first ordering. The description adds nothing beyond that, 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 ('Lists the account's earlier press releases') and goes further by naming what is returned — status and links. The scope word 'earlier' separates it from the draft/publish siblings, though the exact boundary between 'earlier' and current releases is left 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?

Explicit trigger ('Only when the user asks about their earlier releases') paired with an explicit exclusion ('Not needed to draft or publish a new one'), which routes the agent away from create_release and publish_release without it having to inspect those schemas.

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, but the description adds substantial detail beyond them: all validation problems are returned at once, the preview page is private and expires after 7 days, and it contains a publish button. That is exactly the context an agent needs to set user expectations.

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

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

Front-loaded with the purpose and the 'publishes nothing' caveat, and every sentence carries information. The drafting instruction is a long dense run-on that could be split, but no sentence is 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 16-parameter, 12-required tool with no output schema, the description covers what to supply, what comes back (validation errors or a preview URL with a 7-day expiry), and the safety profile. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so fields, formats and limits are already documented. The description enumerates the fields to draft (headline, summary, body, key facts, Q&A, quote, contact, website, image URL), which is helpful framing but adds little syntax or constraint 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 and resource ('Shows how a company's press release will look on LivePublicator') and explicitly separates itself from publishing ('This tool publishes nothing'). It doesn't explicitly contrast with create_release or fix_live_release, so sibling differentiation is only partial.

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 triggers ('use when the user has company news to announce, for example a product launch, a new feature, a partnership or funding') and covers the blog-post case. It implies but never states when to prefer create_release or publish_release instead.

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

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

Annotations cover the safety profile (destructive, idempotent, open-world, non-read-only), and the description goes well beyond them: it discloses the 1-credit cost, the credit refund on failure, the fast-return vs. human-review path with reason and up-to-24-hour expectation. This is the kind of consequence information an agent cannot infer from structured fields.

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

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

Two dense sentences, front-loaded with the action and gated usage, then cost and return behavior. Every clause carries information, though the final credit-refund sentence could be slightly tighter.

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, and the description compensates by explaining both return paths (live link within seconds, or pending review with reason and ETA). Combined with cost and precondition details, an agent has everything needed to call this correctly and interpret the result.

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 adds meaning by tying confirm to the workflow gate ('set confirm to true' after preview approval), reinforcing the schema's stated semantics rather than merely repeating them.

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 ('Publishes the latest saved version of a draft press release'), including scope details (draft page changes, notifying search engines). An agent can readily distinguish this from siblings like create_release, preview_press_release, and update_release.

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

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

Explicitly names the preconditions: only after the user has seen the preview and clearly said to publish, and to set confirm to true. This is exactly the when-to-use guidance an agent needs before a destructive action.

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 by disclosing return content ('the problems to fix, or the updated preview link'), that the whole release is re-validated on every change, and that it costs no credit. With readOnlyHint=false already declared, the description adds the operationally important details of validation feedback and cost.

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 and partial-update rule, followed by return values and cost. 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?

For a 12-parameter mutation with no output schema, the description covers return shape, validation behavior, and cost. It omits what happens if validation fails (e.g. whether the update is still saved) and any precondition that the release must be in draft state, but is otherwise sufficient 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 coverage is 100%, so per-field constraints are already documented. The description still adds real semantic value by clarifying that omitted fields are left unchanged rather than cleared, which the schema alone does not 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?

States a specific verb and resource ('Changes fields of a draft press release') plus the re-validation side effect. The word 'draft' implicitly separates it from fix_live_release, but no sibling is named explicitly, 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 rather than stated: 'draft press release' signals it applies only to unpublished releases, and '(only the fields you send)' signals partial updates. There is no explicit 'use this instead of X when Y' routing against create_release, fix_live_release, or preview_press_release.

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