Smart Post Studio

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

With no annotations, the description carries the full burden; it does disclose the key state transition (scheduled -> draft) and clarifies the operation is non-destructive ('Does not delete anything'), which is valuable. It omits permission/workspace-scope requirements, idempotency, and what happens if the post is not currently scheduled or is already published.

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 clauses, effect front-loaded and the clarifying non-effect second. Nothing wasted 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?

For a 2-param mutation with no annotations and no output schema, the description covers the core semantics but leaves gaps an agent would want: what 'id' refers to, workspace scoping behavior on cancel, and failure modes for posts that aren't scheduled. It is adequate but not fully self-sufficient.

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

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

Schema coverage is only 50%: 'workspace' is documented in the schema, but 'id' has no description anywhere, and the description does not compensate by stating that id is the post identifier. The description adds no parameter meaning at all.

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

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

Specific verb+resource ('Cancel a scheduled post') plus the resulting state ('reverts it to draft'), which separates it from update_post and from any delete tool. It does not name a sibling explicitly, so it stops short of a 5.

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

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

The phrase 'so it will not fire' implies the use case (unscheduling upcoming content), but there is no explicit when-to-use rule, no exclusion (e.g., published or already-draft posts), and no named alternative such as update_post or delete.

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?

No annotations exist, so the description carries the full burden. It usefully discloses that media is fetched server-side with a 25 MB per-item cap and that scheduling has a 10-minute minimum lead time, but says nothing about failure behavior, per-platform validation, permission requirements, or what a successful call returns.

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

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

Two dense sentences with zero filler. The draft/scheduled distinction leads, and the hard constraints follow as supporting detail.

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 5-parameter mutation tool with no annotations and no output schema, the description covers the two non-obvious parameters well but leaves gaps: the tool's return value is unexplained, and there is no mention of cross-platform constraints despite a required multi-platform array.

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 80%, and the description still adds real semantics on top: it states the 10-minute future constraint on scheduled_at (schema only says 'ISO 8601. Omit for a draft') and the server-side fetch plus 25 MB limit on media_urls (schema only says public https URLs). Caption and workspace get no extra meaning, which keeps it below 5.

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

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

States a specific verb+resource ('Create a ... post') and immediately splits the two modes the tool supports: draft vs scheduled. It is clearly distinguished from update_post/cancel_post by the creation framing, 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?

Gives clear selection logic: supply scheduled_at for a scheduled post, omit it for a draft, and the schedule must be ≥10 minutes ahead. No exclusions about when to prefer update_post or how to publish immediately, but the primary branch an agent must decide is spelled out.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the result content (per-platform publishing mode: cloud vs. desktop app), which is genuinely useful, but it omits whether this is a read-only/safe lookup, whether it requires authorization, or how stale the 'right now' status might be.

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 two facts an agent needs (which platforms, how they publish) are delivered immediately.

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

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

For a one-parameter read tool with no output schema and no annotations, the description adequately explains what comes back. A brief note that it is a safe, read-only lookup before create_post would close the remaining gap.

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

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

Schema coverage is 100% and the sole parameter documents the workspace name/id and the default-omission behavior, so the schema does the heavy lifting. The description adds nothing about parameters and cannot be expected to, given the schema's completeness.

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

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

The description names the specific resource (platforms available to a workspace) and its scope ('can post to right now'), plus the extra dimension of cloud vs. desktop publishing. It is not confusable with any sibling (list_posts, create_post, list_workspaces), though it never explicitly distinguishes itself from them.

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?

'Can post to right now' implies the intended use case of checking availability before creating a post, but the description never states when to call it or what to do if a platform is missing. No alternatives or exclusions are named.

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?

With no annotations, the description carries the full behavioral burden. It does disclose one genuine behavioral trait — results only exist after the post fires — but says nothing about authorization, what happens for an unfired post, or what 'per-platform results' contains. Partial disclosure for a read tool with zero annotation coverage.

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

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

A single front-loaded sentence with no waste; the timing qualifier is compactly parenthesized rather than buried. 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?

There is no output schema, so the description is the only place the return shape could be explained, and 'per-platform results' is left undefined (which platforms, what metrics, aggregation?). Adequate for selecting the tool, thin for interpreting what comes back.

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

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

Schema coverage is 50%: workspace is documented in the schema, but `id` has no description. The description's 'one post' implicitly clarifies that `id` refers to a post identifier, which is real added meaning the schema lacks. It still doesn't clarify format (slug vs numeric id) or whether workspace scoping affects lookup.

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

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

Specific verb+resource: 'Fetch one post with its per-platform results', which clearly separates it from list-oriented siblings like list_posts. The parenthetical '(after it fires)' adds a scoping condition. It doesn't explicitly name an alternative, but the singular 'one post' plus the results framing makes the purpose 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?

'(after it fires)' implies a real precondition — the post must already be published for results to exist — which is useful when-to-use signal. However, no alternative is named (e.g. list_posts for browsing, get_connected_platforms for platform availability), and there is no explicit when-not 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?

With no annotations, the description carries the behavioral burden; the verb 'List' implies read-only behavior, and it usefully discloses ordering ('newest first') and the included statuses. It does not explicitly state permissions, default-workspace behavior, pagination semantics, or confirm that no side effects occur.

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 definition is a single front-loaded sentence with no wasted words. It efficiently covers the resource, queue scope, status set, and ordering.

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 listing tool with fully documented optional parameters, the description gives enough context about what is listed and how it is ordered. The lack of output schema is partly mitigated by naming the post statuses, though return fields and default-workspace behavior are left to the schema or inference.

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, status, and workspace meaningfully. The description mentions the status categories but adds no parameter-specific details beyond that baseline, so a 3 is appropriate.

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

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

The description states a specific verb and resource: it lists posts in the queue and names the included statuses. It is clear enough to distinguish a queue listing from mutation tools like create_post or cancel_post, though it does not explicitly contrast itself with get_post_results.

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 strongly implied by 'List the queue' with the four statuses, so an agent can infer this is the broad post-listing tool. However, it gives no explicit when-to-use, when-not-to-use, or alternative guidance against siblings such as get_post_results.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the important default-workspace behavior and scope, but does not state that this is a read-only listing, whether results are paginated, or what fields are returned.

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

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

Two tightly written sentences with the definition and usage front-loaded. Every sentence adds useful information without 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?

Given the low complexity and zero parameters, the description is nearly complete for invocation. Because no output schema exists, a brief note about the return shape would improve it, but the core usage and default behavior are covered.

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

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

The tool has zero parameters, and the description appropriately does not invent any. Its mention of passing a workspace name to other tools is useful context but not a parameter of this 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 and resource: 'List the account's workspaces.' It also explains what a workspace is (separate brands or creators with their own connected accounts and queue), which clearly separates this from the post-oriented sibling tools.

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

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

Explains how to use the result: pass a workspace name to other tools to act inside it, or omit it to use the default. It gives clear context but does not explicitly state when this tool should be called before siblings or any conditions when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the optimistic-locking model and the source of expected_updated_at, but does not say what happens on a version mismatch (error type, retry guidance), whether omitted fields are left untouched, or what permissions are needed for an edit.

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

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

Two tight sentences with no waste; the operation and its fields come first, and the locking prerequisite follows immediately.

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

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

For a mutation tool with no annotations, no output schema, and thin parameter docs, the essentials are present but the failure path (version conflict), partial-update semantics, and return value are unaddressed. An agent could call it but would need to guess how to recover from a stale expected_updated_at.

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 17%, so the description must compensate, and it does: it names the three editable fields and explains the semantics of expected_updated_at (a version token from a fresh read). The mismatch between 'schedule' and the actual 'scheduled_at' parameter plus the undocumented 'id' behavior for partial updates keeps it from a 5.

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

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

States a specific verb ('Update') plus the resource ('an existing post') and enumerates the mutable fields (caption, platforms, schedule). 'Existing' implicitly separates it from create_post, but cancel_post and read siblings are not explicitly 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?

Gives a concrete prerequisite: expected_updated_at must come from a fresh list_posts/get_post_results read, which tells the agent the correct call sequence. It stops short of stating when to prefer cancel_post or how to handle edits where the post was already changed.

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