Postlyra

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered structurally. The description adds genuinely useful behavioral context beyond that: the blast radius is scoped to a single publication ('Other destinations stay unchanged') and prior reads are required — important for a destructive, idempotent write. It stops short of explaining failure/conflict behavior for a destructive op.

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 activation condition, then the scope constraint, then the prerequisite. No filler and no repetition of schema or annotation content.

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

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

An output schema exists, so return values need no explanation, and the description covers trigger, scope, and prerequisites for a two-parameter tool. The one real gap is the semantics/failure mode of expectedRevision, which matters given destructiveHint=true.

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

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

Schema description coverage is 0%, so the description must compensate, and it only partially does: it names publicationId and points the agent to 'read the post revision and publicationId first', hinting where the values come from. It never explains expectedRevision as an optimistic-concurrency guard, which is critical for a destructive tool that should fail rather than clobber a newer revision.

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

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

The description names a specific verb (apply) and a precise resource scope (a working post revision to ONE selected scheduled or delivered Telegram publication), and the clause 'Other destinations stay unchanged' pins down what is not touched. It is clearly distinguishable from broader siblings like update_post or update_post_draft, but it never names an alternative explicitly, so sibling differentiation is implicit rather than stated.

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

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

It gives an explicit trigger condition ('Use when the author explicitly asks to apply a working post revision to one selected... publication') and a prerequisite ('Read the post revision and publicationId first'), which tells the agent to gather inputs before calling. It does not, however, contrast this with update_post, update_post_draft, or publish_post, so the agent gets a when but not a when-instead-of.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds genuinely new behavioral context: pending publications are cancelled, already-delivered Telegram messages survive, and the action is reversible via restore_post. That is exactly the destruction/retention detail an agent needs before calling a destructive 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?

Three short sentences with zero filler; the trigger condition is front-loaded, followed by effect and recovery path. Nothing repeats the name or 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?

An output schema exists, so return values need no explanation. The description covers side effects, retention behavior, and the undo path, which is everything an agent needs to invoke this destructive tool correctly.

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

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

Schema description coverage is 0%, and the description never mentions the single required postId parameter or its format/constraints (1-128 chars). The name is largely self-evident, but the description does nothing to compensate for the documentation gap.

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

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

Names a specific verb+resource (archive a post) plus its side effect (cancel pending publications), and explicitly distinguishes itself from the sibling restore_post. An agent can route to it 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 trigger condition ("when the author asks to archive a post") and points to the inverse operation via restore_post. It does not contrast against other removal-adjacent siblings such as cancel_publication or delete_publication, so the when-not guidance is incomplete.

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 is non-read-only, non-destructive, and non-idempotent. The description adds meaningful context beyond that: it explains how different media types map to block types and explicitly states it does not publish or change existing delivery snapshots, plus implies optimistic concurrency via 'read the post revision first'.

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 tightly written sentences, front-loaded with the usage condition, followed by prerequisite, behavioral mapping, and scope boundary. No filler or redundancy.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. Still, for a mutation tool with a close sibling (attach_media_to_draft), the description lacks explicit sibling differentiation and parameter detail, leaving some ambiguity about when to use this versus its counterpart.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It gives partial cues: mediaId is a 'finalized owner mediaId', postId is a 'working post', and expectedRevision relates to reading the post revision first. But it omits format details, constraints, and what 'owner' entails, leaving significant gaps for an undocumented schema.

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

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

States a specific verb (adding) and resource (finalized owner mediaId to a working post). However, it does not differentiate from the sibling attach_media_to_draft, leaving ambiguity about which attachment tool to use in a given context.

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

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

Provides a clear when-to-use context ('adding a finalized owner mediaId to a working post') and a prerequisite ('Read the post revision first'), but offers no explicit alternatives, when-not-to-use conditions, or guidance on choosing between this and attach_media_to_draft.

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 (which already flag non-readonly, non-destructive, open-world), the description discloses real side effects: it enables a public preview link, may fetch external image URLs during import/rendering, and 'Never publishes'. That is meaningful context for a mutation tool, though the stray 'Returns JPEG' is cryptic.

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 guidance is front-loaded with the use case, then constraints, then follow-up behavior, with almost no filler. It is dense but each clause carries operational information; only the ambiguous 'Returns JPEG' fragment reads as waste.

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

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

For a 10-parameter mutation tool with annotations and an output schema, the description covers selection, limits, formats, placement routing, and side effects adequately. The unexplained references/placementHint params and the unclear return mention are the only material gaps.

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

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

Schema coverage is high (80%), so baseline is 3, and the description still adds value: it explains the slot-vs-array choice, the six-file total cap across both, accepted formats and the 10 MiB limit, and that slot names become richDocument src bindings. It omits mention of the references and placementHint parameters.

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

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

The opening clause states a specific verb+resource ('adding images' to a draft) and explicitly carves out the boundary with update_post_draft for exact placement. However, it never differentiates from the sibling tool attach_media, which an agent would plausibly consider for the same task.

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

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

'Use this when adding images without changing draft text' gives a clear selection condition, and 'Exact placement uses update_post_draft with richDocument slot bindings' names an alternative and when to prefer it. It stops short of a full when/when-not matrix (attach_media and create_media_upload are never referenced).

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, so the safety profile is covered. The description adds real value beyond that: it clarifies that the source post and its history survive, and that in-flight publications are an un-cancelable state. No side effects on the underlying content are left ambiguous.

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 usage trigger, then the guarantee, then the limitation. 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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The description supplies the precondition (must be pending) and the post-condition (source post preserved), leaving only cross-tool routing to siblings unaddressed.

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

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

Schema description coverage is 0% and the single parameter (publicationId) carries no documented constraints in either schema or description. The description's scoping phrase 'one pending publication' implicitly identifies the target, and the parameter name is largely self-describing, but it never states the expected ID format or source.

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 with scope ('cancel one pending publication') and adds a distinguishing behavioral trait ('Preserves the source post and its history') that sets it apart from delete_publication without naming it. Clear, though the sibling contrast 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?

'Use when the author asks to cancel one pending publication' gives a clear triggering context, and 'A publication already being sent cannot be canceled' is an explicit when-not condition. However, it never names the neighboring alternatives (delete_publication, reschedule_publication) that an agent might otherwise choose.

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

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

Annotations already declare it is a non-read-only, non-destructive, non-idempotent write, but the description adds real substance beyond them: what is deep-copied (formatting, media, buttons) and what is deliberately excluded (publication jobs, publishing). It does not mention permissions or that repeat calls yield multiple drafts, but the copy-scope disclosure is the key behavioral fact an agent needs.

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-loaded with the usage condition and then the copy semantics. Every clause carries distinct information with no repetition of the name or 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 two-parameter copy tool with an output schema (so return values need no explanation) and annotations covering the safety profile, the description supplies the essential facts: source, destination type, copied content, and exclusions. Only the optional title parameter 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 0% and the description names neither parameter. 'Reusing an existing post' loosely implies postId is the source, but the optional title parameter for the new draft is completely unaddressed in both schema and prose, so the description fails to compensate for the zero-coverage gap.

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

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

States a specific verb (copy) and resource (post) and immediately scopes it as producing 'a new independent draft', which separates it from create_post_draft. It also enumerates exactly what is carried over (formatting, media, buttons), so the agent knows what a copy means without opening anything else.

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 triggering condition: 'Use when reusing an existing post as a new independent draft.' It also rules out the publication path ('does not ... publish'). However, it never names an alternative tool (e.g. create_post_draft for net-new posts) or states when to prefer one over the other, so the routing guidance is implied 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?

Annotations already establish the safety profile (readOnlyHint=false, destructiveHint=false, non-idempotent), so the bar is lower. The description adds real behavioral value on top: the return payload (short-lived PUT URL, headers, uploadIntentId), the required follow-up step, and the important constraint that the server cannot read a local filesystem path. Auth requirements and URL expiry semantics beyond 'short-lived' are not stated.

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 tightly packed sentences with no filler; the trigger condition, the return contract, the next step, and the filesystem constraint are all front-loaded in roughly the order an agent needs them.

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

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

An output schema exists, so return values need not be explained, yet the description still summarizes them usefully. Combined with the workflow sequencing and the local-path caveat, an agent has enough to invoke this correctly; the only missing pieces are failure modes and parameter constraints that the schema does not supply.

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

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

Schema description coverage is 0% across four parameters, so the description carries the burden. It partially compensates by enumerating the accepted media kinds, which maps to most of the category enum, and by clarifying via the 'local filesystem path cannot be read' note that fileName is a name rather than a path. It says nothing about sizeBytes limits or the expected contentType format, leaving genuine gaps.

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 ('prepare a media upload') and immediately names its counterpart, finalize_media_upload, making the two-step flow unambiguous. It also enumerates the supported asset kinds (image, video, document, audio, voice), so an agent can distinguish this from the unrelated attach_media/attach_media_to_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 a clear when-to-use trigger ('uploading a local image, video, document, audio or voice file') and spells out the required follow-up call to finalize_media_upload. It does not, however, explain when to prefer this over siblings such as attach_media or attach_media_to_draft, so the routing decision is only partially covered.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false; the description adds genuine value by stating 'Never publishes' (draft-only side effect) and 'May fetch external image URLs during import or screenshot rendering' (network behavior), consistent with openWorldHint=true. It stops short of noting rate limits or non-idempotency consequences.

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 dense and front-loads the core use case, then packs workflow steps into short imperative fragments. Every clause carries information, though the telegraphic fragment style is slightly choppy rather than smoothly structured.

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 17-parameter tool with nested objects and an output schema, the description covers the key workflow, precedence, media binding, external-fetch behavior, and non-publishing guarantee. Return values are noted even though an output schema exists, making it nearly complete, with only edit-vs-create routing 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 76%, which already documents most parameters including the richDocument override rule and media slot bindings. The description reiterates the media.src binding (mediaFile1..mediaFile6 or mediaFiles) and the override precedence, adding little 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?

The opening sentence gives a specific verb and resource ('creating a Telegram draft'), which is clear and actionable. It distinguishes itself from publishing siblings via 'Never publishes,' but does not explicitly separate itself from update_post_draft or attach_media_to_draft, so sibling differentiation is 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?

Strong workflow routing: 'Read get_formatting_capabilities,' 'prefer finished richDocument,' and 'Inspect preview_post' tell the agent exactly what to do before and after. It also gives a precedence rule (richDocument overrides text/preset/template). It lacks an explicit when-not-to-use clause or a pointer to update_post_draft for edits.

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-destructive write, so the safety bar is lower. The description adds genuinely new context: the resulting template is owner-only and is not published, which is information annotations do not carry. It does not mention duplicate creation despite idempotentHint=false.

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

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

Two tight sentences with the trigger condition front-loaded, followed by the required inputs and the key side-effect. No filler.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. The definition covers the essential call shape and the owner-only/no-publish outcome, but omits the optional metadata parameters and any duplication behavior.

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

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

Schema description coverage is 0% across 5 parameters, so the description must carry the burden. It identifies the two required inputs (name and the document, referred to as "RichDocument" rather than the schema's documentJson) but says nothing about locale, category, or description, leaving three optional parameters undocumented anywhere.

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 ("Creates an owner-only template") and the intended trigger (saving a reusable post layout). It lacks explicit differentiation from update_template/delete_template/list_templates, which the agent must infer from the tool 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?

"Use when the author asks to save a reusable post layout" gives a clear usage condition rather than a vague one. It does not name alternatives (e.g. update_template for modifying an existing template) or state when not to use it, so routing still requires some inference.

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

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

Annotations already declare destructive=true, idempotent=true, and openWorld=true, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: the blast radius explicitly excludes the source post and messages in other destinations, telling the agent what is NOT destroyed. It stops short of stating that the published message removal is permanent/irreversible.

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 precondition 'Use only when the author explicitly asks', followed by the action and the survivors clause. Every sentence carries distinct information with no repetition of 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 destructive tool with annotations and an output schema, the definition covers the precondition, the target, and the unaffected resources – what an agent needs to call it safely. The only gap is not stating whether the deletion is permanent or recoverable, which matters for a destructive operation.

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

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

Schema description coverage is 0% for the single publicationId parameter, so the schema documents only type and length bounds, not meaning. The description partially compensates by indicating the id identifies the previously published message, but adds no format, source, or example. With one parameter and no schema prose, this is adequate but thin.

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 (delete) and a clearly bounded resource: one message previously published by Postlyra, identified by publicationId. It implicitly separates itself from siblings like cancel_publication or archive_post by scoping to already-published messages, though it never names the nearest alternative. Clear and specific, but the sibling differentiation is left implicit rather than stated.

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

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

Gives an explicit precondition – use only when the author explicitly asks to delete – which is stronger than typical 'when to use' text and functions as a guardrail. It does not name cancel_publication or reschedule_publication as the alternatives for other intents, so the routing guidance is clear but not exhaustive.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds a genuinely non-obvious behavioral fact beyond that: posts already created from the template survive deletion, i.e. no cascading delete. It does not mention irreversibility or required ownership/permissions.

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 waste: the trigger condition is front-loaded and the second sentence carries a distinct, useful consequence. Nothing is repeated from 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?

An output schema exists, so return values need no explanation, and annotations carry the destructive/idempotent profile. What remains thin is the parameter story (no pointer to list_templates for the ID) and the irreversibility of deletion, but for a one-parameter destructive tool the description 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?

Schema description coverage is 0% and the single parameter templateId has no description in either schema or prose. The phrase 'their saved template' weakly implies the template must belong to the author, but nothing says where to obtain the ID or what format it takes, so the description does not compensate for the coverage gap.

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

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

The description pairs a specific verb (delete) with a specific resource (saved template), and the title narrows the scope to a 'personal' template. It is clearly distinguishable from resource-different siblings like delete_publication or archive_post, though it never names a sibling explicitly.

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

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

It states an explicit trigger: use when the author asks to delete their saved template. There is no guidance on alternatives (e.g., update_template, list_templates to find the ID) or on when deletion is inappropriate, so it stops short of a 5.

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

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

Annotations cover the safety profile (non-read-only, idempotent, non-destructive, closed-world), and the description adds the failure mode ('expired or invalid uploads are rejected') plus what is actually checked (content, size, ownership). It does not spell out the retry/re-upload path, but that is a meaningful addition beyond the structured hints.

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

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

Three tight sentences: prerequisite first, then verification behavior and output, then failure handling. No filler and nothing buried.

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

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

With an output schema present, the description need not explain the returned mediaId structure, and it correctly focuses on sequencing, verification scope, and rejection behavior. Only the semantics of the input identifier remain thin.

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

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

Schema description coverage is 0% for the single uploadIntentId parameter, so the description must carry the load. It implies the identifier originates from the create_media_upload call, which is useful, but never names the parameter or states its format/lifetime.

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 (verify/finalize an uploaded file) and distinguishes itself from siblings by naming both the producer (create_media_upload) and the consumer (attach_media). An agent can place this tool in the workflow 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?

Explicitly gives the ordering condition: use after uploading bytes to the URL returned by create_media_upload. It does not state when not to use it or what to do on rejection, but the workflow context is unambiguous.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the substantive detail that authorization flows through Telegram and account linkage, but says nothing about what happens on an unauthorized result or any caveats beyond that.

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

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

A single front-loaded sentence with no filler; the condition and the resource are packed into one clause and nothing is repeated from the schema 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?

An output schema exists, so return values need not be described, and the description covers the tool's scope adequately for a parameterless status check. It could be marginally stronger by indicating what an agent should do when the check fails, but nothing essential 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 per the baseline there is nothing for the description to clarify. The description correctly avoids inventing inputs and pins the implicit target as the 'current MCP caller'.

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 (check) and a precise resource (whether the current MCP caller is authorized via Telegram and linked to a Postlyra account). No sibling tool covers auth status, so it is unambiguously distinguishable from the post/template/workspace tools listed.

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

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

It gives an explicit use condition — 'use this when you need to check whether the current MCP caller is authorized' — which is a clear trigger. It stops short of any exclusions or alternatives, though in this case no sibling offers an overlapping capability.

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 behavior, so safety is covered. The description still adds real value by disclosing an important scope restriction (no private Telegram Business conversations, no sending), which is not implied by the annotations.

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

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

Two sentences, front-loaded with the 'Use when' trigger, and every listed category is meaningful rather than filler. The final exclusion sentence is slightly tacked-on but still earns its place.

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

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

For a simple read-only tool with an output schema (so return format needn't be explained), the description covers purpose scope, triggering conditions, and important exclusions. The only gap is the undocumented locale parameter.

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

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

There is one optional parameter (locale, enum ru/en) with 0% schema description coverage, and the description says nothing about it. The agent gets no guidance on what the locale controls (result language vs. filter) or how omission behaves, so the description fails to compensate for the coverage gap.

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

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

The name/title plus the enumerated categories (unfinished drafts, formatting or media problems, lost permissions, failed deliveries, publication gaps) make clear this retrieves content items that need attention. It is specific about the resource scope, but never states exactly what it returns and does not distinguish itself from siblings like get_post or search_post_drafts.

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 definition is explicitly usage-first, listing concrete triggering situations ('reviewing unfinished drafts, formatting or media problems...'), and adds a negative scope boundary ('Does not read private Telegram Business conversations or send messages'). It stops short of naming alternative tools to use instead, so it is strong but not exhaustive.

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

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

Annotations already establish this as a safe, read-only, idempotent, closed-world call. The description adds genuinely useful context beyond that: it must be called first, once per task, and enumerates the contract contents (blocks, inline marks, nesting, limits, uploads, error recovery, presets, next step). It stops short of stating caching or token-size characteristics of the returned contract.

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, all front-loaded: the imperative call-first directive leads, followed by what Postlyra produces and what the return payload contains. Every sentence carries distinct information with no repetition.

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

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

An output schema exists, so return values need not be detailed, yet the description still summarizes the contract's scope and adds the sequencing rule ('first, once per task'). Nothing an agent needs to invoke this 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?

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond the (empty) schema, and it correctly signals a parameterless call.

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 (get Postlyra formatting capabilities / RichDocument contract) and precisely scopes what it returns. It is clearly distinguishable from the neighboring post/workspace/template mutation tools, none of which expose formatting contracts.

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 when-to-use: 'call it FIRST, once per task' when composing or formatting any post, and a when-not-to-look-elsewhere note ('Telegram MarkdownV2/parse_mode documentation is not needed'). It does not name sibling alternatives, but no real alternative exists for this prerequisite lookup, so the gap is minor.

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 covered. The description adds real context beyond them: it returns the *working document / current revision* and explicitly performs no preview or publish side effect, which distinguishes it behaviorally from preview_post.

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 zero filler and the primary use condition front-loaded in the first clause. Every sentence carries information.

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

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

An output schema exists, so return-value explanation is largely unnecessary, though the description helpfully characterizes the returned object as the working document. The remaining gap is the missing semantics for the 'postId' parameter.

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

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

Schema description coverage is 0% for the single required parameter 'postId'. The description never mentions the parameter or its expected format (ID vs slug vs UUID), even though the schema only supplies a length constraint. With a non-trivial required identifier, the description should compensate and does not.

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

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

States a specific verb and resource ('reading an existing post and its current revision'), which lets an agent distinguish it from preview_post, publish_post, and update_post by effect. It stops short of naming the sibling tools it is not, so it is clear but not maximally differentiated.

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 scopes usage to reading before editing, and rules out the adjacent workflows ('without enabling a public preview or publishing anything'), which implicitly routes the agent away from preview_post and publish_post. No named alternatives, but the condition for use is clear.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the content scope (quotas, storage, chat count, time zone), which is modest incremental value, but says nothing about auth requirements, freshness of the data, or failure behavior.

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

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

A single front-loaded sentence with no filler; the 'Use when' prefix puts the trigger first and every listed field 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?

An output schema exists, so return values need not be described, and annotations cover safety. However, for a read tool whose whole purpose is scoping and identity, the description omits that it reflects the authenticated account's workspace and gives no hint of behavior when no workspace is available — minor but real gaps.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4 and no parameter explanation 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?

The description is phrased purely as a trigger ('Use when checking...') and never states the operation — that it returns the current workspace's settings/quotas. The four listed fields imply what the tool surfaces, but the agent must infer the verb+resource, and nothing distinguishes it from siblings such as update_workspace or get_auth_status.

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

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

It gives a concrete usage context — 'before planning content' — and enumerates the conditions (quota, storage, chat count, time zone) that should prompt the call. It stops short of naming alternatives like update_workspace for changing those settings, so it is strong but not a full when/when-not guide.

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

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

Annotations already establish readOnly, idempotent, non-destructive, and closed-world behavior, so the bar is low. The description still adds a real behavioral constraint not present in structured data: results are limited to channels/groups/chats the *authorized* user can manage, which tells the agent to expect a permission-filtered, potentially empty result and that no auth escalation is described.

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 usage cue followed by the resource and scope. Nothing is wasted, but the sentence is thin enough that its brevity reflects limited content rather than tight editing.

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

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

For a zero-parameter, read-only listing tool with an output schema present and full annotation coverage, the description supplies everything needed: what is listed, and the permission scope of the listing. Return values are correctly delegated to the output schema.

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

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

The tool takes zero parameters, which sets the baseline at 4. The schema is empty with additionalProperties false, and the description correctly adds no parameter guidance because none is needed, though it also supplies no filtering options the agent might expect (there are none).

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

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

The description names a specific verb ("list") and a concrete resource ("Telegram channels, groups, and chats"), and adds scope the tool name alone does not convey: only assets the authorized user can manage through Postlyra. That scope distinguishes it clearly from the post/publication/template siblings, though it does not explicitly reference any sibling by name.

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

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

"Use this when you need to list..." identifies the triggering scenario but the condition is essentially a restatement of the tool's function. There is no statement of when not to use it or which sibling covers adjacent needs (e.g., listing publications vs. channels), so usage is only implied rather than routed.

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 non-destructive, so safety is covered. The description adds real value beyond that by disclosing the return contract ('returns publicationId') and its role as the prerequisite for reschedule/cancel/edit/delete chaining, which annotations cannot express. Pagination behavior is left unstated.

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 the usage trigger front-loaded and zero filler; every clause either scopes the tool or explains why an agent would call it.

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

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

An output schema exists, so return-shape explanation is not required, and annotations cover the safety profile. However, with seven undocumented parameters and no enum values, an agent cannot tell how to filter by time range, channel, post, or status, leaving the definition only minimally usable for invocation.

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

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

Schema description coverage is 0% across 7 parameters, so the description carries the full explanatory burden, yet it never mentions from/to, limit, offset, postId, channelId, or the accepted status values. The phrase 'scheduled publications, delivery failures or messages previously published' only vaguely gestures at the status filter and leaves the time-range and scoping filters opaque.

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

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

The description gives a specific verb-and-resource framing ('inspecting scheduled publications, delivery failures or messages previously published') and the title reinforces it as a calendar read. It is clearly distinct from write siblings like cancel_publication or reschedule_publication, though it does not name them explicitly.

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

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

'Use when inspecting scheduled publications, delivery failures or messages previously published' states the triggering conditions clearly, and the follow-up sentence implies this is the discovery step before rescheduling, cancellation, editing or deletion. No explicit exclusions or named alternatives are given, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds that template ids are returned, but says nothing about pagination, filtering behavior, or ordering that would extend beyond the annotations. Adequate but not rich.

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

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

It is short, but the structure is disjointed: the standalone fragment 'Optional for custom composition' is ambiguous about what is optional and for whom. The actual purpose statement is deferred to the final clause. Every sentence roughly earns its place, but the ordering and fragment hurt readability.

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 zero required parameters, an output schema present, and annotations covering safety, the main remaining need is usage routing, which the description supplies. Nothing essential for calling it correctly is missing, though a note on how category/channelId narrow results would round it out.

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 category and channelId are already documented in the schema, and the description mentions neither. The description's note that ids are returned is output-related rather than parameter-level, so it adds no parameter meaning. 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 ends with a concrete verb+resource statement: 'this tool lists saved templates and their ids.' It distinguishes itself from get_formatting_capabilities, which is named explicitly. The purpose is clear, though it is buried at the end of the description rather than front-loaded.

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

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

It gives an explicit trigger ('Use this when the user wants an existing reusable Postlyra layout template') and routes the agent away to get_formatting_capabilities for supported blocks and JSON/formatting questions. No explicit when-not condition is given, but the alternative tool is named and the condition that selects it is clear.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, destructiveHint=false, but the description adds genuinely new behavior: it may fetch external image URLs during rendering, it is safe to retry 'unavailable' screenshots without recreating the draft, and it never publishes. The note to follow display.instruction and check screenshot.truncated is operational guidance not derivable from annotations, and nothing contradicts them.

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

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

Front-loaded with the trigger and then moves through returns, alternative, and operational caveats in a logical order. Dense with several clauses packed into a short block, but each sentence carries distinct information; only the display.instruction/screenshot.truncated clause feels slightly terse for its importance.

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

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

An output schema exists, so return values need not be fully described, yet the description nonetheless names the key return artifacts (documentJson/richHtml, JPEG) and preview-link creation. Combined with the retry/no-recreate guidance and external-fetch disclosure, an agent has everything needed to call this complex, open-world tool correctly.

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

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

Schema coverage is 0% for the single draftId parameter, but the description compensates by naming its provenance ('Find draftId with search_post_drafts'), which is exactly what the schema lacks. It does not describe the ID's format or type, keeping it below a 5, but the sourcing hint is materially useful.

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 (preview a draft post), and immediately enumerates the three outputs it produces: screenshot, public browser preview, and validation warnings. It explicitly distinguishes itself from the sibling show_post_card for in-chat cards, so an agent can route without opening either schema.

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

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

Gives an explicit trigger condition (requesting screenshot/public preview/validation warnings), tells the agent how to obtain the required draftId (search_post_drafts), and names the alternative (show_post_card) with its distinct purpose. When-not guidance is also present via 'Never publishes.'

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, openWorldHint=true and idempotentHint=true, so the safety profile is partly covered. The description still adds real behavioral context beyond them: idempotencyKey should be reused on retry, and queued/retrying status means pending rather than delivered. It stops short of describing irreversibility or failure modes.

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

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

Front-loaded with the usage condition and the safety-critical preconditions, then tacks on retry and status semantics. Four dense sentences with little waste, though the prerequisite list could be tightened.

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

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

An output schema exists, so return-value documentation is not required. For a 5-param, destructive, externally-visible write with low schema coverage, the description supplies the authorization gate, prerequisite tool chain, and async status caveat — everything needed to call it correctly.

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

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

Schema description coverage is only 20% (channelId alone is documented), so the description must compensate, and it largely does: it explains channelId resolution via list_channels, the confirmed=true flag, the confirmationText authorization payload, and idempotencyKey retry semantics. draftId itself is never described.

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 (publish a reviewed existing Postlyra rich draft to a connected Telegram channel) and explicitly differentiates itself from the draft tools: 'This is the external publication action; draft tools never send.' An agent can distinguish it from schedule_post, apply_post_to_publication and create_post_draft 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 precondition for use ('when the user explicitly authorizes publishing a reviewed existing... draft') plus a prerequisite workflow naming sibling tools (resolve channelId via list_channels, inspect via preview_post, supply confirmed=true with confirmationText). Nothing about when-to-use 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.

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

Annotations already disclose idempotent=true, destructiveHint=true, and openWorld=false, lowering the burden. The description adds the useful scope constraint "Does not change its content," but says nothing about what happens if the publication is no longer pending or what the destructive hint implies for the prior schedule.

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: when-to-use first, then required inputs, then a scope boundary. Every sentence earns its place with no redundancy.

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

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

An output schema exists, so return values need not be explained. The two params are covered and the non-content-change scope is stated. Minor gaps remain around preconditions (must the publication still be pending?) and the destructive semantics, but overall it is complete enough to invoke.

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

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

Schema coverage is 0%, so the description must carry parameters. It names publicationId and clarifies that scheduledAt must be a concrete ISO date with a UTC offset, which is format detail the bare date-time schema does not convey. This meaningfully compensates for the missing schema descriptions.

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

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

States a specific action (change date/time) on a specific resource (one pending publication), which naturally distinguishes it from schedule_post and cancel_publication. It stops short of naming those siblings explicitly, but the verb+resource+scope combination is unambiguous.

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

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

"Use when the author asks to change the date or time of one pending publication" gives a clear triggering condition and implicitly limits it to pending items. It does not name alternatives (schedule_post, cancel_publication) or state when-not to use it, so it falls short of the top band.

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

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

Annotations already declare non-read-only, idempotent, non-destructive, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond the annotations — canceled publication jobs are not restarted — and clarifies the resulting state is a working draft.

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

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

Two tightly written sentences, front-loaded with the usage condition, and every clause contributes new information (draft outcome, canceled-job behavior) with no redundancy.

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

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

With an output schema present and annotations covering idempotency and destructiveness, the remaining burden is light. The description covers the trigger, the outcome state, and one edge behavior, though it omits error conditions (e.g., what happens when the post is not archived) and permission requirements.

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?

One parameter at 0% schema description coverage, so the description must carry the load. It implies the postId must reference an archived post, which is meaningful, but adds no format, length, or error-handling detail for the ID itself.

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

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

The description gives a specific verb (restore) and resource (an archived Postlyra post) plus the resulting state ('as a working draft'), which is more than a restatement of the name. It implicitly contrasts with archive_post but never names a sibling, so it falls short of full differentiation.

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

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

'Use when restoring an archived post' supplies a trigger condition (only applies to archived posts), but there is no when-not guidance, no mention of archive_post as the inverse operation, and no prerequisites such as permissions.

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, destructiveHint and openWorldHint, so the safety profile is largely covered. The description adds meaningful behavioral context beyond that: the server applies shared publishing rules and stores an immutable delivery snapshot, and it flags the idempotency requirement. It still does not explain reversibility or how cancellation interacts with the snapshot.

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

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

Three tight sentences with the usage condition front-loaded, followed by input constraints and behavioral notes. No filler; each sentence adds information. Slightly dense but well ordered.

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

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

An output schema exists, so return values need no explanation, and annotations cover the mutation/idempotency profile. Still, for a 6-parameter mutation linking a post and channel at a scheduled time, the description omits expectedRevision's role and the postId/channelId relationship, leaving noticeable gaps.

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

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

Schema coverage is only 17% — just the timezone field is documented — so the description must compensate and only partly does. It clarifies the scheduledAt format (exact ISO date with UTC offset) and the idempotency key requirement, but postId, channelId and expectedRevision carry no semantic explanation in either place.

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

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

The description states a specific verb and resource: scheduling a post to a connected channel or group. This is clearly distinct from publish_post or reschedule_publication in intent. It stops short of explicitly naming how it differs from those siblings, so it is clear but not fully self-differentiating.

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 supplies a trigger condition, 'when the author explicitly asks to schedule a post,' which is useful guidance. However it names no alternatives (publish_post, reschedule_publication) and gives no when-not guidance or prerequisites such as channel connectivity or permissions.

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 structured. The description adds valuable behavioral context beyond annotations: emphasizes it never edits, enables sharing, or publishes, and explains pagination via nextCursor/hasMore and owner-only IDs/snippets. However, it doesn't detail rate limits or auth requirements, leaving a modest gap.

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

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

The description is compact and front-loaded with the primary use case, then flows into constraints and related tools. Some sentences like 'Matches all keywords/fragments in title and rich text, ignoring case' are slightly redundant with the schema but still earn their place for clarity.

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 has an output schema (so return values needn't be explained) and rich annotations, the description covers all an agent needs: purpose, when to use, alternatives, behavior, and pagination. Nothing critical is missing for correct invocation.

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

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

Schema coverage is 100%, so the schema fully documents all three parameters. The description adds only marginal value with 'Empty query lists recent drafts', which is already covered in the query parameter's schema description. Baseline 3 is appropriate when schema does the heavy lifting.

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 ('search_post_drafts' for 'finding an existing draft') and explicitly distinguishes from siblings search_posts and preview_post. An agent can identify the tool's function without opening the schema.

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

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

Explicitly states when to search first ('when draftId is unknown'), what not to do ('do not ask for a link'), and names alternative tools show_post_card and preview_post with their distinct purposes. Complete routing guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds that it searches owner content and the archived scope, but says nothing about pagination behavior (limit/offset) or result ordering, which would be the useful additions.

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 usage trigger, then the searchable facets, then the follow-up tool. No filler and nothing repeated from the schema 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 an output schema present, return values need no explanation, and the annotations cover safety. The remaining shortfall is pagination and includeArchived semantics on a schema with zero parameter descriptions, but the core search behavior is adequately conveyed.

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

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

Schema description coverage is 0%, so the description must carry the burden. "by words, status, connected channel and update dates" maps to query, status, channelId and from/to, covering the main filters, but limit, offset and includeArchived are left unexplained for an 8-param tool.

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

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

States a specific verb (find/search) and resource (Postlyra post) and even clarifies the scope: scheduled, published or archived content. It routes to get_post as the follow-up reader. However, it never distinguishes itself from the closely-named sibling search_post_drafts, leaving that differentiation to inference.

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

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

"Use when finding any existing Postlyra post" gives clear context, and "Read the selected post with get_post" names the alternative for retrieval after selection. The one obvious gap is the sibling search_post_drafts, whose relationship is not addressed, so there are no explicit exclusions.

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

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

Annotations declare readOnlyHint/idempotent/non-destructive, and the description is consistent with them while adding real behavioral context: it never publishes or schedules on its own, opens no public link, and what to do if the tool is unavailable (refresh connection metadata). This resolves the apparent tension between a read-only hint and a UI that offers scheduling.

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?

Five short sentences, front-loaded with the usage trigger before the mechanics and the negative scoping statements. Dense but each sentence does work; the fallback sentence is the most peripheral yet still useful for error recovery.

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

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

An output schema exists so return values needn't be described. The description covers prerequisites, visual rendering behavior, what it does not do (publish/schedule/public link), and the degraded-client path — enough for an agent to invoke it correctly in this 30-tool sibling set.

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

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

Schema coverage is 0% for the single postId parameter, so the description must carry the load; it does by telling the agent where the value comes from ('pass the found post ID as postId' from search_posts/search_post_drafts). It does not clarify format expectations beyond the schema's 1-128 char string, which is a minor gap.

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

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

States a specific action (render the post card UI inside chat) with its scope (preview, text editing, scheduling), and explicitly distinguishes itself from lookalikes: 'A screenshot or preview_post URL is not this UI.' An agent can separate it from preview_post, get_post, and update_post 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?

Names the triggering condition ('when the author asks to show a post card inside the chat or choose publication controls there') and the required upstream step ('After search_posts or search_post_drafts, pass the found post ID as postId'). It also gives a fallback path for clients without UI support.

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

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

The annotations already convey mutation, destructiveness, and non-idempotency. The description adds meaningful behavioral context beyond annotations: the optimistic-concurrency requirement (read revision first) and the snapshot isolation for scheduled/sent messages until an explicit apply step. This enriches the safety profile without contradicting annotations.

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

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

Three sentences, each earning its place: the first scopes the action, the second gives a critical precondition, the third clarifies the boundary of effect. Front-loaded and free of fluff.

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

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

The tool has 7 parameters, nested objects, and an output schema. The description covers use cases, concurrency, and scope, but it does not explain the structure of inlineButtons or how locale affects the operation, and the schema itself is thin on these details. Given the complexity, a bit more guidance would make it fully complete, though the presence of annotations and an output schema mitigates the gaps.

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

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

Schema description coverage is only 14%, so the description must compensate. It links 'content, title, buttons or attention flag' to likely parameters (documentJson, title, inlineButtons, needsAttention) and hints at expectedRevision with 'Read its revision first', but it fully ignores locale and gives no structure hints for inlineButtons or documentJson beyond what the schema states. Partial compensation, but gaps remain.

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

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

The description states a specific verb ('changing') and resource ('a post's working content, title, buttons or attention flag'), which clearly distinguishes it from siblings like update_post_draft and apply_post_to_publication. It also names the sibling for applying changes to scheduled/sent messages, removing any ambiguity about the tool's scope.

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

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

It opens with an explicit when-to-use ('Use when changing...'), gives a precondition ('Read its revision first'), and explains when not to use it ('Scheduled and sent messages remain on their own snapshots until apply_post_to_publication is requested'), naming the alternative tool. This is textbook usage 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?

While annotations already mark the call as destructive and non-read-only, the description adds meaningful side effects: it replaces layout with text, may fetch external image URLs, returns a JPEG, and enables a public preview link. No statement contradicts the annotations.

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

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

The description is front-loaded with usage and prerequisites and contains useful side-effect/display notes. It is slightly redundant ('Read preview_post' appears again as 'Inspect preview_post'), but overall every sentence contributes to correct invocation.

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 tool with 15 params and nested objects, the description provides the essential workflow: read preview, get formatting capabilities, submit a complete richDocument, display the resulting image, and avoid publishing. An output schema exists, so not detailing every return field is acceptable; a small gap is the lack of explicit guidance for non-draft workflows.

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 73% and the schema already documents richDocument, text, and mediaFile slot semantics in detail. The description condenses these ('Send the complete edited richDocument...', 'Bind imported file slots as media.src') but adds little information beyond the schema, and it does not clarify undocumented params like templateId or appendCallToAction.

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

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

The description opens with 'Use this when editing a draft' and repeatedly frames the action as updating a Postlyra draft, ending with 'Never publishes.' It clearly identifies the target resource and verb, but it never explicitly contrasts with the sibling update_post tool, so it does not fully disambiguate from all alternatives.

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

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

The first sentence gives an explicit use condition ('when editing a draft') and the description includes hard exclusions ('Never publishes') and required precursor reads ('Read preview_post and get_formatting_capabilities'). It does not name alternative tools for non-draft publishing scenarios, stopping just short of the full when/when-not/alternatives guidance.

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

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

Annotations already convey that this is a mutation (readOnlyHint=false) and potentially destructive (destructiveHint=true). The description adds a meaningful behavioral boundary: only the author's own templates are editable. It does not go further to explain update semantics (e.g., whether provided fields replace the whole template), but the annotation coverage lowers the burden.

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

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

The description is a single compact sentence that front-loads the action and resource, then states the key limitation. Every word earns its place and there is no redundant restating of 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 tool with six parameters, a nested object, and a destructive annotation, the description is thin: it omits any information about what fields mean, whether partial updates are allowed, and what happens to omitted fields. The output schema and annotations fill some gaps, but the lack of parameter guidance leaves the definition only minimally 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 0%, so the description bears the responsibility for explaining parameters, but it does not mention templateId, name, locale, category, description, or documentJson at all. The schema property names are somewhat self-explanatory, but the description adds no guidance about which fields are editable or how documentJson relates to the template.

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

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

The description clearly identifies the action ('changing') and the resource ('the author's saved template'), and distinguishes it from related sibling tools by explicitly stating what cannot be edited: system templates and other users' templates. This gives an agent a clear match for the update_template operation.

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

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

The description states when to use the tool ('when changing the author's saved template') and gives an important exclusion: system templates and other users' templates cannot be edited. It does not explicitly name an alternative tool for those excluded cases, but the context is clear enough for an agent to route around them.

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

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

Annotations already convey that the tool mutates state (readOnlyHint=false) and is idempotent, so the description does not need to restate those. The added fact that existing publication times are untouched is useful behavioral context beyond the annotations. However, it does not disclose overwrite behavior or whether omitted parameters are preserved.

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 with no filler: the first states when to use the tool, the second states an important boundary. The key trigger is front-loaded, and 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?

Given the output schema exists and annotations cover the mutation/idempotence profile, the description covers the main decision points: when to use, what it changes, and what it explicitly does not change. It could mention that omitting a parameter leaves that preference untouched, but the optional-parameter schema plus the wording makes this reasonably inferable.

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

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

Schema description coverage is low (33%), and the description compensates by mapping each parameter to plain language: time zone, weekly publication target, and content reminder preference. It does not explain cadencePerWeek's 0-70 range, the meaning of 0, or that all parameters are optional independent updates, so it adds some but not full semantic value.

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

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

The description uses a specific verb ('change') and names the exact resources: time zone, weekly publication target, and content reminder preference. It also explicitly distinguishes itself from scheduling tools by stating 'Does not change existing publication times.' An agent can tell what this tool is and is not for.

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

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

The description gives an explicit trigger condition ('Use when the author asks to change...') and a clear exclusion ('Does not change existing publication times'). It does not name alternative sibling tools like reschedule_publication or schedule_post, but the when/when-not guidance is strong enough for an agent to route correctly.

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