PostPlanify

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

Annotations only declare readOnlyHint=false, openWorldHint=false and destructiveHint=false, so the description adds real value: it discloses the eligibility constraint and that cancellation is terminal (cannot be rescheduled). It does not say what happens to the post record afterward or what errors occur for non-scheduled IDs, and the destructiveHint=false is slightly at odds with an operation that permanently ends a post's 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?

Three short sentences, the core action front-loaded and each following sentence earning its place by stating a constraint or consequence. No filler.

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

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

For a one-parameter state-change tool with no output schema, the description covers eligibility and irreversibility well. A minor gap remains around the resulting state of the post and error behavior for invalid IDs, but nothing essential to invoking it correctly is missing.

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

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

There is a single parameter with 100% schema description coverage, so the schema already documents postId fully. The description adds no syntax, format, or ID-source detail beyond the schema, making 3 the appropriate baseline.

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 (cancel) and resource (scheduled post), which is clear and actionable. It does not explicitly distinguish itself from the sibling delete_post, leaving the agent to infer the difference between cancelling a scheduled post and deleting 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?

"Only scheduled posts can be cancelled" gives an explicit precondition, and the note that a cancelled post must be replaced by a new post communicates the consequence of use. It stops short of naming an alternative tool (e.g. delete_post) for non-scheduled posts.

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, openWorldHint=true), so the bar is lower. The description adds non-trivial behavioral context the annotations cannot express: the future-datetime requirement, platform-specific validation gates, and the fact that IDs must be sourced from other tools before calling. It does not describe scheduling vs. immediate-publish semantics or failure behavior, so it falls 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?

Front-loaded with the core action and ID provenance, then a clearly delimited PLATFORM NOTES block; every line carries a distinct constraint. Minor redundancy (YouTube/TikTok media requirements restate schema-level information), keeping it just short of optimal.

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 14-parameter tool with nested objects and no output schema, the description supplies the cross-parameter rules that decide whether a call will succeed per platform, plus the datetime constraint. Remaining gaps (isStory, utmCampaign, shortenLinks, X-specific fields) are already documented in the schema, so coverage is adequate though not exhaustive on side parameters.

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

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

Schema description coverage is 100%, so the baseline is 3. The description goes beyond the schema by documenting cross-field dependencies the schema cannot express — which parameter combinations each platform demands and where socialAccountId, mediaIds, and boardId originate. That is genuine added meaning over per-parameter text.

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

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

States a specific verb+resource ('Create and schedule a new social media post') and scopes it to exactly one social account, which distinguishes it cleanly from edit_post, delete_post, and cancel_post. It also names the sibling tools that supply its inputs (list_social_accounts, upload_media_from_url, list_media), so an agent can place it in the workflow without opening other schemas.

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 explicit context for use: per-platform prerequisites (Instagram needs media, YouTube needs video + title, Pinterest needs boardId) and the constraint that scheduledAt must be a future ISO 8601 datetime. It routes the agent to the correct sibling tools for obtaining IDs. It stops short of explicit when-not/what-to-use-instead guidance for create vs. edit paths, so it 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 and readOnlyHint=false, so the safety profile is covered structurally. The word 'Permanently' usefully reinforces irreversibility, but the description says nothing about side effects such as what happens to posts or comments referencing the deleted media, or whether authorization beyond the ID is required.

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 the verb, resource, and key constraint; there is no filler and nothing to trim.

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

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

For a one-parameter destructive tool with annotations covering the safety profile and no output schema, this is nearly sufficient. The only meaningful omission is downstream impact on content that references the deleted media.

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% for the single mediaId parameter, so the baseline is 3. 'By its ID' adds no format, source, or validation detail beyond what the schema already states.

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 ('delete'), resource ('uploaded media file'), and lookup key ('by its ID'), which clearly separates it from delete_post and cancel_post in the sibling list. It stops short of explicitly naming an alternative, but the resource 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?

There is no when-to-use guidance, no prerequisites (e.g., ownership or workspace scoping), and no mention of alternatives such as list_media for locating the ID first. Usage must be inferred entirely from the tool name and description.

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 safety profile is covered. The description adds the irreversibility guarantee ('cannot be undone'), which is genuinely useful context beyond the annotation. It stops short of permissions requirements or confirmation 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?

Two short sentences, with the destructive nature and irreversibility front-loaded. Nothing 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 single-parameter delete tool whose annotations already carry the destructive/read-only profile, the description covers what an agent needs: the operation and its irreversibility. It omits what happens on a missing/invalid postId and any return confirmation, but no output schema exists to compensate.

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% for the single postId parameter, so the schema already documents it fully. The description adds no syntax, format, or sourcing detail beyond what the schema provides; 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 (delete) and resource (post), with the added qualifier 'permanently' that sharpens scope. It does not distinguish itself from the sibling cancel_post, which is the nearest plausible alternative for undoing a post.

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

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

No guidance on when to use this versus cancel_post, no prerequisites, no mention of what conditions must hold before deleting. The usage is only implied by the name.

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 usefully adds the 'scheduled-only' editability constraint, but says nothing about reversibility, whether omitted fields are preserved, or what happens if the post publishes mid-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?

Three short sentences, each earning its place, with the core action and the hard constraint front-loaded and the patch rule placed last.

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?

Adequate for a concise mutation tool, especially since the 11-parameter schema is fully self-documenting. Still, with no output schema and nested platform-specific objects, the description says nothing about response shape or failure modes, and the patching rule could be stated more explicitly.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns above baseline with 'Only include the fields you want to change,' which establishes patch/partial-update semantics that the schema alone does not convey.

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 ('Update a scheduled post') and scopes it with a clear precondition. It doesn't name or contrast with siblings like create_post or cancel_post, but the scope makes it distinguishable.

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?

'Only scheduled posts can be edited' is a real eligibility constraint, so usage is implied and bounded. However, it names no alternative workflow (e.g., cancel_post + create_post to change a published post) and gives no guidance on post state transitions.

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 structurally. The description adds genuinely new context by disclosing the returned metric categories and the notable behavior that output is 'platform-specific data format', but it says nothing about permissions, rate limits, or whether a date range is implied or defaulted.

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 that are front-loaded with the core purpose and then the payload contents; no filler or repetition of the title. It could be tighter, but 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?

With no output schema, the description correctly takes on the burden of describing return values, naming both account-level and post-level metrics plus the platform-specific format caveat. The remaining gap is routing context (time range or when to prefer get_analytics_trends), which is a modest omission for a two-parameter read tool.

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

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

Schema description coverage is 100% for both parameters, so the schema already explains workspaceId and socialAccountId. The description adds no parameter-level meaning (no ID format, no note that both are required, no scope caveats), 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?

States a specific verb and resource ('Get analytics data for a specific social account') and enumerates the metric families returned (followers/following, views/likes/comments/engagement rate). It is clear on its own, but it never distinguishes itself from siblings like get_analytics_trends or get_brand_overview, leaving the agent to infer which analytics tool to pick.

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 or when-not-to-use guidance, and no mention of the two obvious alternatives in the sibling set (get_analytics_trends, get_brand_overview). The agent gets no signal about whether this is the per-account snapshot versus the trend or brand-level view.

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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description usefully adds the return shape ('daily snapshots') and the scoping by day count, but says nothing about pagination, data freshness/latency, rate limits, or permission requirements for a read-only analytics call.

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 resource and return payload front-loaded and zero filler; nothing could be removed without losing 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?

With no output schema, the description does the necessary work of stating what comes back (daily follower growth and engagement snapshots) and the time scoping. It is nearly complete for a read-only analytics tool; only freshness/latency and pagination behavior are unstated.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including the days default (30) and max (365). The description only echoes the day-window concept ('specified number of days') without adding format or semantics beyond the schema, so the baseline 3 applies.

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

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

The description gives a specific verb+resource ('Get historical trend data for a social account') and names the concrete payload ('follower growth and engagement metrics over time'). It is clear enough to distinguish from a current-snapshot sibling like get_account_analytics by the word 'historical/over time', but it never names or contrasts 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?

Usage is only implied by 'over time' and 'historical' – an agent can infer this is for trend/backfill questions rather than point-in-time analytics, but the description gives no explicit when-to-use, when-not-to-use, or alternative (e.g. get_account_analytics).

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 safe-read profile (readOnlyHint, destructiveHint false, openWorldHint false), so the description only needs to add scope context — and it does, disclosing the fixed 7-day window, the set of connected accounts included, top 10 posts, and daily trend series. It stops short of noting freshness/latency or whether the window is configurable.

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, zero filler, with the purpose front-loaded and the content enumeration immediately after. Every clause earns its place by telling the agent what the aggregate contains.

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

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

With no output schema, the description does the work of explaining the return shape (accounts, 7-day metrics, top 10 posts, daily trends), which is exactly what an agent needs to judge applicability. Minor gaps remain around data freshness and whether the 7-day window can be adjusted.

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% for the single workspaceId parameter, so the schema already carries parameter meaning and the baseline of 3 applies. The description says 'for a workspace' but adds no format, source, or validity constraints beyond the schema.

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

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

States a specific verb and resource (aggregated analytics overview for a workspace) and enumerates the payload contents, which separates it conceptually from account-level siblings like get_account_analytics. It does not, however, explicitly name those siblings or state the workspace-vs-account distinction as a routing rule.

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: reach for this when you need a broad workspace-level snapshot rather than per-account or per-post detail. There is no explicit when-to-use, when-not-to-use, or named alternative among the many analytics/list siblings, so the agent must infer the selection rule.

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 by structured data. The description adds that the target is the authenticated user and that this doubles as a connectivity check, but says nothing about what the response contains despite there being no output schema.

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

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

Two short sentences, purpose first, usage second, with no filler. Every clause earns its place.

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

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

For a trivial read-only, zero-parameter tool the description covers purpose and usage adequately. The one remaining gap is the shape of the returned profile, which neither the description nor an output schema supplies.

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 calibration this is the baseline of 4; there is simply no parameter semantics to explain.

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: 'Get the authenticated user's profile.' This is clearly distinguishable from sibling reads such as get_workspace or get_social_account, 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 concrete usage contexts ('verify the connection is working', 'get user context'), which is good guidance for a zero-parameter probe tool. It stops short of stating when-not-to-use or naming an alternative.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral value beyond that by explaining that `metrics` is null for unpublished posts or uncollected analytics, and that null differs from zero — a real interpretation hazard for the caller.

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: what is retrieved first, then the edge-case semantics. No filler, no repetition of the title or annotations.

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

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

With no output schema, the description carries the burden of describing returns and it does so well by listing the included fields and the null-metrics edge case. The only gap is not indicating where a valid postId comes from, which would help an agent chain calls correctly.

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

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

Schema description coverage is 100% for the single postId parameter, so the baseline is 3. The description only alludes to 'a specific post' and adds no format, origin (e.g., from list_posts), or validity detail beyond the schema.

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

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

The description uses a specific verb ('Get') and resource ('a specific post'), then enumerates exactly what is returned (content, status, media, publishing logs, performance metrics). It is clearly distinct from list_posts by scope, but it never names a sibling or explicitly contrasts itself with tools like get_analytics_trends.

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

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

Usage is only implied: the agent can infer this is the tool for fetching one post's full detail by postId. There is no explicit 'use this when...' statement, no prerequisites, and no guidance on when to prefer it over get_account_analytics or get_analytics_trends for performance data.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds nothing beyond that – no error/not-found behavior, no auth or scope requirements, no indication of what 'details' are returned, and no output schema to compensate.

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

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

A single short sentence with no filler, and the resource is front-loaded after the verb. It is efficient, though it is arguably under-specified rather than maximizing the space available.

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 full annotation coverage, the description is minimally viable. The gap is that with no output schema, the agent gets no sense of what fields 'details' returns or how a missing/inaccessible account is signaled.

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

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

Schema description coverage is 100% and the single accountId parameter is documented in the schema itself. The description adds no format, source, or acquisition guidance for the ID, so the baseline 3 applies.

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

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

Clear verb+resource: 'Get details about a specific connected social account.' The word 'specific' implicitly contrasts with the list_social_accounts sibling, but the sibling is never named, so differentiation is inferential rather than explicit.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as list_social_accounts or get_account_analytics. The agent must infer that this tool is for fetching one account by ID.

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 only the scope of the payload (includes connected social accounts); it says nothing about lookup failures or how much 'detailed info' is returned. No contradiction with 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?

A single front-loaded sentence with no filler or repetition. It is efficient, though 'detailed info' is slightly hand-wavy and 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?

For a simple one-parameter read with no output schema, the definition covers the essentials. But the vague 'detailed info' leaves the returned fields under-specified, and no error behavior for a bad/missing workspaceId is given.

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% (workspaceId fully documented), so the baseline is 3. The description adds no syntax, format, or provenance detail for the ID beyond what the schema already states.

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 (get) and resource (workspace) plus the notable return content (connected social accounts), so an agent knows exactly what it retrieves. It does not, however, distinguish itself from the similar-looking list_workspaces sibling.

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 guidance on when to use this over list_workspaces, nor any precondition (e.g., knowing a workspaceId) or mention of the alternative. The 'specific workspace' phrasing implies a single-record lookup but leaves selection 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 cover the safety profile (readOnlyHint, destructiveHint=false, openWorldHint). The description adds two useful behavioral facts beyond that: results are only direct replies (not recursive threads) and LinkedIn URNs must be passed raw without URL encoding.

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, each carrying a distinct payload (what it returns, where the ID comes from, the URN encoding caveat). Purpose is front-loaded and 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?

For a single-parameter read-only tool with no output schema, the description covers purpose, input provenance, and the one real gotcha (URN encoding). No pagination or return-shape note, but 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 baseline is 3. The description adds meaning over the schema by telling the agent where the ID comes from and giving a concrete LinkedIn URN format example that the schema does not provide.

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 a scoping qualifier: 'direct replies to a specific comment'. This naturally separates it from list_comments and reply_to_comment, though no sibling is named 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 concrete provenance for the required input ('Use the `id` returned from list_comments as the platformCommentId'), which is exactly the context needed to call it. It does not state when-not to use it or name an alternative for threaded/nested retrieval.

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, openWorldHint=false, so the safety profile is covered. The description usefully adds that only top-level comments are returned and enumerates the returned fields (author, text, platform, post context, read/hidden state), which matters given there is no output schema. It does not mention pagination or rate-limit behavior.

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

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

Three tight sentences, front-loaded with what is listed and where it comes from, then return contents, then use case. No filler or repetition, and every sentence earns its place.

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

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

With read-only annotations, 100% schema coverage, and no output schema, the description supplies the missing return-shape information and use context. Pagination behavior is left to the schema, which is acceptable but the only 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 description coverage is 100%, including enum values and defaults, so the schema carries the parameter burden. The description only echoes the platform set already enumerated in the schema and adds no syntax or format detail beyond it, making the baseline 3 correct.

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 comments and reviews) scoped to a workspace, and names the exact platforms harvested. The phrase 'top-level comments' implicitly differentiates it from list_comment_replies, so an agent can tell the two apart 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 clear when-to-use guidance: triaging an inbox, or resolving a comment ID before replying (which routes toward reply_to_comment). It lacks any explicit when-not-to-use statement or a named alternative, 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 cover readOnly/destructive/openWorld, so the safety profile is known. The description adds real context beyond that: the scope difference between calls with and without workspaceId, and the meaning of the per-item 'source' field ('library' vs 'upload').

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

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

Four short sentences, front-loaded with the core purpose and then the branching semantics; no filler. Slightly dense in the middle sentences but every clause 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?

No output schema exists, and the description compensates by describing the returned item's 'source' field and the two id families. Pagination is left to the schema's page/pageSize descriptions, which is reasonable for a 4-parameter read tool.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds cross-tool meaning beyond the per-parameter text: it explains the concrete result-set consequence of passing workspaceId and confirms that both id kinds are accepted downstream by create_post.

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 media that can be attached to posts') and implicitly distinguishes itself from upload_media_from_base64/upload_media_from_url/delete_media in the sibling set. An agent can tell what this returns without opening the schema.

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

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

Gives explicit conditional guidance: include workspaceId to get the dashboard library plus API/MCP uploads, omit it to get only API/MCP uploads. It also notes both id kinds are valid in create_post, which frames when this tool is useful. It does not name a sibling alternative explicitly, so it stops short of 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=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the downstream linkage to pinterestParams.boardId, but says nothing about pagination, rate limits, or what a board record contains.

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

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

Two short sentences with zero filler; the purpose is front-loaded and the follow-on usage note is kept to a single clause.

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

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

For a one-parameter read-only list tool with no output schema, the description covers what it returns (boards) and why the IDs matter, which is enough to call it correctly. Return field details are absent but not critical here.

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% for the single accountId parameter, so the baseline is 3. The description does clarify the semantics of the returned board IDs (usable as pinterestParams.boardId), which is modest added value beyond the schema but not parameter syntax or format 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?

The description states a specific verb and resource ('List Pinterest boards') scoped to a Pinterest account, which cleanly separates it from list_posts, list_media, and list_workspaces. It does not explicitly name a sibling it competes with, 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 second sentence supplies concrete context: 'Pinterest posts need one of these board IDs as pinterestParams.boardId,' which tells the agent this is a prerequisite step before creating a Pinterest post. There are no explicit exclusions or named alternatives, so it is clear context rather than full when/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?

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description still adds real behavioral context: results are paginated, and a null metrics field means no analytics collected, which is explicitly distinguished from a zero value. It does not describe pagination metadata or rate/limit 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?

Front-loaded with purpose, output shape, the required parameter, and the status vocabulary, then a second short paragraph for the metrics flag. No filler sentences; every clause conveys a distinct fact.

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

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

With no output schema, the description carries the return-shape burden and does reasonably well: pagination, per-post metrics, and null-vs-zero semantics are covered. It omits pagination metadata (total pages/counts) and the general post field set, which an agent might want before relying on the response.

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 baseline is 3. The description goes beyond it by enumerating the metric fields returned when includeMetrics is true (views, likes, comments, shares, engagement rate) and restating the status vocabulary as usable values, which adds practical meaning not spelled out in the schema.

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

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

States a specific verb and resource ('List posts with filters') plus output shape ('Returns paginated results'), which distinguishes it from mutation siblings like create_post/delete_post. It does not explicitly name its closest sibling get_post, but 'instead of fetching them one at a time' implicitly draws the bulk-vs-single distinction.

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

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

Gives a clear use case for includeMetrics ('compare how posts performed') and names the alternative pattern it replaces (fetching posts one at a time). It lacks explicit when-not guidance for the tool itself, e.g. when to prefer get_post for a single known post.

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 genuine value beyond that by enumerating exactly what is returned (account IDs, platform types, account names), which is the key thing an agent needs since there is no output schema.

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

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

Three short sentences, front-loaded with the core action and scope, then return contents, then the practical follow-up tip. 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?

With no output schema, the description must carry the return-value burden, and it does list the returned fields and the full platform enumeration. The main remaining gap is no hint about pagination or result size for an account list spanning all workspaces.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly indicates the tool is unfiltered and global, matching the empty 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 ('List') and resource ('connected social media accounts') with scope ('across all workspaces'). It implicitly contrasts with the singular get_social_account sibling via the 'all' scope, but never names an alternative 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?

The closing sentence gives downstream guidance ('use the returned account IDs when creating posts'), which implies the typical workflow, but there is no statement of when to call this versus get_social_account or get_account_analytics. Usage is only inferable from the tool's name and scope.

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 only the access-scoping fact ('workspaces the user has access to'); it says nothing about pagination, ordering, or return shape beyond the implicit ID mention. Adequate but thin on top of annotations.

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

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

Two short sentences, zero filler, with the core action stated first and the usage hint second. Every sentence earns its place.

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

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

For a simple, annotation-covered, zero-parameter list tool with no output schema, the description covers purpose, scope, and motivation sufficiently. The only gap is the absence of a sibling contrast with get_workspace, which is minor here.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies a no-argument listing operation, and there is no parameter semantics to clarify.

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 all workspaces') and adds the clarifying synonym 'brands' plus the scope 'the user has access to'. It is clear what the tool does, though it does not explicitly contrast itself with the singular sibling get_workspace, so the agent must infer the plural/singular split.

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

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

Explicitly says when to use it: 'Use this to find workspace IDs needed for other operations like listing posts or social accounts.' This gives a clear motivating context and names downstream tools, but it never states an exclusion (e.g., when get_workspace is the better choice), so it stops short of full 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 only cover the safety profile (readOnly=false, destructive=false, openWorld=true); the description adds genuinely useful behavior beyond that: immediate publication, platform-specific length caps, the hidden-comment restriction, the brandReplied side effect on the parent comment, and the LinkedIn URN encoding quirk.

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

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

Four short sentences; the core action is front-loaded, then constraints, side effects, and the platform-specific gotcha follow in descending order of importance. 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?

No output schema exists, and the description compensates by disclosing the success side effect (brandReplied=true) and the key failure mode (hidden comments), so an agent has everything needed to call this correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: per-platform character limits for message and the instruction to pass a raw, non-URL-encoded URN for platformCommentId on LinkedIn — details absent from the schema.

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

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

States a specific verb and resource ('Post a public reply to a comment') plus the scope ('on its originating platform'), which cleanly distinguishes it from siblings like create_post, edit_post, and list_comment_replies.

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 usage condition: reply to an existing comment, with an explicit exclusion ('Cannot reply to hidden comments'). It does not name alternatives (e.g., list_comment_replies) or state what to do when replying is impossible, so it stops short of full 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 only declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false; the description goes well beyond them by disclosing a hard 20MB size limit, the exact set of accepted formats, the fact that the file is stored without compression or resizing, and that the result is a media ID attachable to a post. These are precisely the operational constraints an agent needs before attempting an upload.

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, zero filler, and the ordering is sensible: what it does, the condition that selects it, then constraints and return value. Every sentence contributes information an agent can act on.

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

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

There is no output schema, and the description compensates by naming the return value ('a media ID that can be attached to a post'). Combined with size and format limits, nothing an agent needs to invoke this tool correctly is missing.

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

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

Schema description coverage is 100% and all three parameters are documented there, including the mimeType enum. The description's format list ('JPEG, PNG, GIF, WebP, MP4, MOV, PDF') and mention of base64 content largely restate that enum and the 'data' parameter rather than adding new semantics. Baseline 3 applies when the schema carries the 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 ('Upload a file sent as a base64-encoded string') and immediately scopes it against the sibling upload_media_from_url with the conditional 'for files that are not available at a public URL.' An agent can distinguish this from the URL-based upload sibling 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 usage condition is stated explicitly ('for files that are not available at a public URL'), which effectively routes the agent away from upload_media_from_url, and the supported-format list tells the agent whether this is even a valid path. It stops short of naming the alternative tool outright, so it is clear context rather than a full when/when-not/alternative 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 this is a non-read-only, open-world, non-destructive write. The description adds real behavioral context beyond that: it fetches from an external URL over the network, enumerates accepted formats (JPEG/PNG/GIF/WebP/MP4/MOV/PDF), and tells the agent the operation returns a media ID for later use. It omits size limits, auth requirements, and failure modes for unreachable URLs.

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 core action, then formats, then downstream usage. Minor redundancy: the workflow's step 2 'Note the returned media ID' restates the preceding sentence about using the returned media ID when creating posts. Still tight overall.

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

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

With no output schema, the description correctly explains that a media ID is returned and how to consume it, plus accepted formats. For a two-parameter upload tool this is near-complete, though practical limits (file size, URL accessibility, auth) are unstated.

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

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

Schema description coverage is 100%, so both parameters are already documented, including the 'public URL' constraint and the filename fallback rule. The description only reinforces that the source is a public URL and never mentions the optional filename parameter, so it adds nothing over 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+resource ('Download a file from a public URL and upload it to PostPlanify') and scopes it to media for posts. The phrase 'primary way to add images and videos' implicitly separates it from the sibling upload_media_from_base64, which handles the other input source.

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 context (adding media for use in posts) and a 3-step workflow ending in create_post. It never explicitly states when to prefer upload_media_from_base64 over this tool, so the base64 alternative is left to inference rather than named.

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