AutoPoster AI

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

Annotations already cover readOnly/destructive/openWorld, so the bar is lower. The description adds meaningful behavioral context beyond that: the link is 'short-lived,' it must be handed to the user, the agent should wait for confirmation, and then it should verify via autoposter_list_media before attaching. This is genuinely useful operational detail.

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

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

Three sentences, front-loaded with the core action before usage guidance and the follow-up workflow. Every sentence earns its place. The final sentence is dense but functional rather than wasteful.

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

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

An output schema exists, so return-value details are not required. With no parameters and annotations covering the safety profile, the definition supplies what's needed to invoke and sequence the call. The main remaining gap is explicit differentiation from the similarly named get_media_upload_url sibling.

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 (empty object, 100% coverage), so the baseline is 4. There are no parameter semantics for the description to clarify, and it adds nothing that could mislead about inputs.

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

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

States a specific verb and resource: 'Creates a short-lived link where the user can upload images ... into the Auto Poster media library.' This is clear and non-tautological. However, it does not distinguish itself from the close siblings autoposter_get_media_upload_url and autoposter_upload_media, so an agent must still infer which is the right one.

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

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

Gives a precise trigger condition: use it 'when the user wants to attach an image that exists only in the chat or on their device (no public URL) and your client cannot send file contents.' It even prescribes the follow-up workflow. It stops short of explicitly naming the alternative tools (autoposter_upload_media / autoposter_get_media_upload_url) to contrast against.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this mutates state. The description adds genuinely useful scope (draft/scheduled/pending only, and that it can 'cancel' rather than only hard-delete), but says nothing about irreversibility, permissions, or what happens to a post mid-publish.

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

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

One sentence, front-loaded with the verb, with the eligible-state qualifier and key attached compactly. Nothing is redundant or padded.

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

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

An output schema exists, so return values need not be described, and annotations carry the safety profile. The description covers the resource and eligible states; only minor gaps remain, such as whether cancelling a scheduled post is recoverable and what occurs if the post is already published.

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

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

Schema coverage is 100% for the single postId parameter, and the description adds nothing beyond 'by ID' — no format, prefix, or accepted-ID-source detail. Baseline 3 applies when the schema already carries the full parameter meaning.

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

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

States a specific verb pair ('deletes or cancels') and the resource ('draft, scheduled, or pending post') plus the lookup key ('by ID'). It scopes which post states are eligible, but never names a sibling tool, so an agent must infer the boundary against autoposter_publish_draft or autoposter_get_post on its own.

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

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

Usage is implied by the state list: draft/scheduled/pending posts are deletable, which weakly signals that published posts are not. There is no explicit when-to-use versus when-not, no alternative tool named for other cases, and no prerequisites stated.

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

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

Adds real context beyond annotations: the approval workflow (pending_approval + notifications to approvers), media size limit (100MB), and the fallback to a public URL. Annotations cover safety (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the description's role is to add workflow detail, which it does well.

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

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

Four sentences, well front-loaded: core behavior first, then approval fallback, then media rules, then escalation path. Only minor redundancy in restating the URL alternative, but 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?

Covers creation behavior, approval flow, media constraints, and escalation for large files. An output schema exists, so return values need not be described. For a 7-param tool with nested objects, it leaves minor gaps (e.g., platformContent override details) but is otherwise 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 coverage is already 100%, so the baseline is 3; the description adds practical semantics by clarifying mediaUrls' 100MB limit and the files alternative ('AI-generated images or uploaded files from chat'), which goes beyond the schema.

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

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

States a specific verb+resource ('Creates a draft post') and distinguishes from siblings like autoposter_publish_draft by emphasizing human review. The pending_approval fallback and media-acceptance rules make the intent unmistakable.

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

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

Explicitly routes large-media cases to autoposter_get_media_upload_url, and explains the alternative path (public URL) when the 100MB limit is exceeded. It also clarifies when the post becomes pending_approval, giving clear when-to-use 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=false, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine operational context the annotations cannot: a 5GB ceiling, no server-side size limits or timeouts, and the shape of what comes back (PUT url, POST upload fields, public CDN URL). It does not mention auth/credential requirements for the presigned URL, which would be the next useful detail.

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

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

A single dense sentence, but it is correctly front-loaded: the disqualifying precondition and the alternative come before the output details, which is exactly the order an agent needs for routing. The trailing enumeration of return values is slightly list-like but each item earns its place.

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

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

With an output schema present, the description need not explain returns, and it still summarises them. Combined with the routing precondition and size/timeout characteristics, an agent has enough to select and invoke correctly. Only the credential/auth expectation for the presigned URL is left implicit.

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

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

Schema description coverage is 100% with only fileName and contentType, both fully documented in the schema with examples. The description adds no parameter-level detail beyond the tool's general purpose, so the baseline 3 is appropriate when the 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?

States a specific verb and resource: 'Generates a presigned S3 upload URL for direct, high-speed upload of videos or images'. It also names the sibling it is not (autoposter_create_upload_link), so the agent can distinguish the two upload paths 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?

The first clause is an explicit precondition: only for clients that can perform an HTTP PUT or multipart POST, not chat-only clients such as Gemini. It names the alternative tool and the exact condition that selects it, which is about as clear as routing guidance gets.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed-world scope, so safety is covered. The description adds the post state vocabulary and the presence of live link receipts, which is modest added context. It says nothing about behavior for missing/invalid IDs or non-owned posts, so it is adequate rather than 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?

A single front-loaded sentence with no filler; the core operation comes first and the returned facets follow compactly.

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 read-only annotations carry the safety profile; the single required param is fully documented. The only real gap is sibling disambiguation against autoposter_get_post_status, which leaves the definition slightly short of 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?

With a single parameter at 100% schema description coverage, the schema already documents postId fully. The phrase 'by ID' restates the schema without adding format, source, or validation semantics, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Retrieves a single post by ID') plus the returned facets (state values, live link receipts), so the agent knows exactly what it gets. However, it never differentiates itself from the sibling autoposter_get_post_status, and the enumerated state values overlap with what that sibling likely does, which could cause ambiguity.

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

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

There is no when-to-use guidance, no condition selecting this over autoposter_get_post_status or autoposter_list_posts, and no stated prerequisites. The agent must infer the use case from the name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, so the safety profile is covered. The description adds useful timing context ('once published') for when links/receipts become available, but says nothing about caching, freshness, or polling behavior for posts still in flight.

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

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

A single front-loaded sentence with zero filler. The operation and the result are both stated up front, and no sentence is wasted.

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

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

With an output schema, annotations covering safety, and a fully documented single required parameter, the definition supplies enough for an agent to call it correctly. The only mild gap is that it does not clarify behavior for pending/failed posts, which would have been helpful for a status-check tool.

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

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

There is one parameter with 100% schema description coverage ('The post ID to query.'), so the schema fully documents it. The description adds no extra meaning about the postId format or origin, which is the expected baseline when the schema does the work.

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

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

The description names a specific verb and resource ('checks delivery status of a post') and adds the return payload ('live platform links/receipts once published'). It implicitly distinguishes itself from autoposter_get_post by focusing on delivery/publication state, but 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?

Usage is only implied: an agent can infer this is the tool for post-delivery checks, but there is no explicit when-to-use, when-not-to-use, or alternative routing versus autoposter_get_post or autoposter_list_posts. No prerequisites or context conditions are stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds that the payload is constraint metadata, but says nothing about freshness (whether platform rules are live or cached) or scope across platforms. With annotations carrying the safety profile, this is adequate but thin.

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

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

One compact sentence with the resource front-loaded and no filler. 'Guidelines' is mildly vague but the earlier enumeration carries the meaning.

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

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

An output schema exists, so return structure need not be spelled out, and there are no parameters to document. For a simple read-only getter this is nearly complete; only the absence of when-to-call guidance leaves a small gap.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The description correctly implies a parameterless, fetch-everything call rather than suggesting a platform filter that does not exist.

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 clear verb ('Returns') and a well-scoped resource ('platform publishing constraints') and enumerates the content types (character limits, media format requirements, guidelines). It is clearly distinct from the write/upload/media siblings, though it does not name any 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?

Usage is only implied: an agent can infer this should be consulted before posting or uploading to check limits, but the description never states when to call it or what it replaces. No prerequisites or exclusions are given.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine value by scoping results to the 'current Autoposter workspace', which the annotations do not convey. It stops short of describing result shape, but an output schema exists to carry 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 that identifies the resource, its platform coverage, and its workspace scope with no filler. Nothing in it is redundant with the title or name.

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

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

For a zero-parameter, read-only list operation with an output schema and full annotation coverage, the description supplies everything an agent needs to select and call it. Return values are legitimately 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, so there is no parameter semantics to document; the baseline of 4 applies. The description correctly avoids inventing filters that the schema does not support.

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 ('Lists') and resource ('connected social media accounts') with an explicit scope ('current Autoposter workspace') and enumerates the supported platforms. This clearly separates it from sibling list tools such as autoposter_list_posts and autoposter_list_media.

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

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

Usage is implied rather than stated: an agent can infer this is the discovery step for obtaining account handles/IDs before drafting or scheduling posts. There is no explicit when-to-use guidance, no mention of prerequisites, and no named alternative, but for a zero-parameter read tool the space of alternatives is narrow.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that results carry public CDN URLs, a useful behavioral detail, but says nothing about pagination behavior or the workspace scoping beyond 'workspace media library'.

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 resource and the distinguishing return detail (public CDN URLs) come first and nothing is wasted.

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

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

For a simple read-only list tool with an output schema and full parameter documentation, the description covers what is needed. It omits any note on result ordering or pagination beyond the limit param, but the output schema carries return-shape detail.

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 type enum, limit default (20), and max (50) are all documented in the schema itself. The description adds no parameter semantics beyond what the schema provides, which is the expected baseline when the 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?

States a specific verb (lists) and resource (media files in the workspace media library), plus the fields returned (images/videos with public CDN URLs). It is clearly distinct from upload-oriented siblings, but it never explicitly differentiates itself from autoposter_upload_media or autoposter_get_media_upload_url.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as autoposter_get_media_upload_url for obtaining an upload target. The agent must infer usage purely from the one-line purpose statement.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds only that filtering dimensions exist, without disclosing pagination behavior, result ordering, or how empty results are signaled. That is acceptable but thin against an already-safe read tool.

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

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

Two short sentences with the core scope front-loaded and no filler. The state enumeration partially duplicates the schema enum, which is mild redundancy but not bloat.

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?

Because an output schema exists, the description need not explain return values, and its coverage of the three optional filters aligns with the schema. For a simple zero-required-parameter list tool this is essentially sufficient; only the sibling routing guidance is missing.

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

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

Schema description coverage is 100%, so the schema already documents limit (default 20, max 50), state, and search. The description restates the filterable fields and the state values, adding no format, default, or matching semantics beyond the schema. Baseline 3 applies.

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

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

States a specific verb and resource ('Lists posts in the workspace') and enumerates the dimensions it can filter on, so the agent knows exactly what operation it performs. It does not, however, differentiate itself from siblings like autoposter_get_post or autoposter_get_post_status, which an agent must infer.

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

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

Usage is implied by the filtering capabilities (browse/filter posts in bulk), but there is no explicit statement of when to choose this over autoposter_get_post for a single post or get_post_status. No prerequisites or exclusions are given.

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

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

Annotations only declare readOnlyHint=false, destructiveHint=false, openWorldHint=true. The description adds meaningful context annotations lack: the required auth scope (direct publish permission) and that publication is immediate and follows an approval step. It stops short of stating reversibility or rate limits.

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

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

Two short sentences with zero waste; the publish action is front-loaded and the auth requirement follows. Nothing extraneous.

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 mutation tool with an output schema and non-destructive annotations, the description covers purpose and the key auth prerequisite. A note on what happens to the draft afterward or error conditions would round it out, but it is largely complete.

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

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

Schema coverage is 100% and the only parameter (postId) is already fully documented as 'the post ID returned by autoposter_draft_post.' The description adds nothing beyond that, so baseline 3 is appropriate.

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

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

States a specific verb ('approves and immediately publishes') and resource ('existing draft or pending post'). The word 'immediately' implicitly distinguishes it from schedule_post, though it never names that 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?

Provides a precondition (API key with direct publish permission) but no explicit when-to-use-vs-alternatives guidance. The 'immediately' phrasing hints at the schedule_post distinction, but the agent must infer that scheduling a future post uses a different tool.

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

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

Annotations establish the write/mutation profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true). The description adds genuinely useful non-obvious behavior: automatic local-to-UTC conversion via workspace/user timezone, the 100MB attachment ceiling, and a fallback path for oversized files. Return values are covered by the output schema.

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

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

Three sentences, front-loaded with the core scheduling action, then timezone behavior, then media handling. Dense and mostly waste-free, though the media sentence packs several distinct concepts together.

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 9 params, full schema coverage, and an output schema, the description supplies the operationally important extras: timezone conversion, media size limits, and the oversized-file escape hatch. It stops short of documenting platform applicability or permission requirements, but the enum hint and annotations cover most of that.

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 already 100%, so the structured fields document themselves. The description nonetheless adds cross-parameter meaning by clarifying the three media paths (mediaUrls public URLs, files for chat-generated/uploaded media, mediaIds from the library) and the size constraint, which the schema does not state.

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

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

States a specific verb and resource ('Schedules a post for a future date/time'), which is clear and actionable. It implicitly differs from siblings like draft_post and publish_draft, but never explicitly contrasts them, leaving the agent to infer which lifecycle stage this represents.

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 an explicit conditional alternative for the >100MB video case ('use autoposter_get_media_upload_url'), which is strong. However, it gives no guidance on when to schedule versus draft or publish, so the primary routing decision among sibling tools is left unaddressed.

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 write (readOnlyHint=false), open-world, and non-destructive, so the safety profile is already covered. The description adds genuinely useful behavioral context beyond that: the 100MB direct-download ceiling, the 5GB S3 path, and the source-type constraints that determine whether the call will succeed. It does not mention auth requirements or failure modes, which keeps it short of a 5.

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

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

The main capability and the size ceiling are front-loaded, then the two escape hatches follow in descending order of relevance. Every sentence carries a routing decision; there is 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 described. Between the accepted sources, the size limits, and the two named alternatives, an agent has everything needed to decide whether to call this tool and how to escalate when it cannot.

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

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

Schema description coverage is 100% and both 'url' and 'file' are already documented in the schema, including the data-URI and ChatGPT file-object semantics. The description's source list (DALL-E output, uploads, public URLs) largely restates that, adding only the size context. Baseline 3 is appropriate.

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

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

States a specific verb and resource ('Uploads an image or video to Auto Poster media library') and immediately scopes the accepted input sources. It explicitly distinguishes itself from the two most confusable siblings, autoposter_get_media_upload_url and autoposter_create_upload_link, so an agent can route 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 concrete when-to-use conditions: use this tool for ChatGPT-generated files, uploaded files, or public URLs up to 100MB; use autoposter_get_media_upload_url for >100MB / S3 uploads up to 5GB; use autoposter_create_upload_link when the asset exists only in chat or on the user's device. Alternatives are named with the exact condition that selects each.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real behavioral value beyond that: the identifier is opaque and stable across token refresh, reconnection, and display-metadata changes, which tells the agent it can safely cache the id.

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

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

Two sentences with no filler. The core action is front-loaded in the first sentence, and the second earns its place by documenting id stability properties an agent would otherwise not know.

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 needn't be described, and the zero-param signature needs no explanation. The description covers purpose and a key behavioral property of the returned id; only minor auth-context detail is absent, which is acceptable.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and it correctly does not invent parameter detail.

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

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

States a specific verb and resource: 'Return the profile represented by this request's authenticated credentials.' The scope (the caller's own profile) is unambiguous, and the sibling set consists entirely of unrelated autoposter_* tools, so no in-family differentiation is required.

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 use case is implied by the description ('this request's authenticated credentials'), making it self-evident this is the way to fetch the current identity. However, there is no explicit when-to-use statement, no mention of alternatives, and no stated prerequisites, leaving usage to inference.

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