Publish a prepared post (step 2 of 2)

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

Adds meaningfully beyond annotations: the action is irreversible through the API and requires prior user confirmation. It also states the return payload (new post's ID and link), which matters since there is no output schema. The one gap is that it doesn't say whether the preview expires or what error state a stale container_id produces, so the irreversibility warning isn't fully operationalized.

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 step and the action, with the irreversibility warning and confirmation gate immediately after. Every sentence contributes, but the description leans entirely on the sentence-per-idea structure without any extra framing, so it earns a solid but not standout mark for economy.

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, no-output-schema publish tool, the description covers the workflow position, the confirmation prerequisite, the irreversibility, and the return values. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100% and the single parameter is already documented as coming from ig_prepare_post. The description only echoes the provenance constraint already in the schema, adding nothing about format or lifetime of the container_id. Baseline 3 applies 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: making a draft from ig_prepare_post public on the account. It explicitly frames itself as step 2 of the ig_prepare_post workflow, so an agent can distinguish it from the prepare 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?

Gives an explicit prerequisite: only call after the user has seen the ig_prepare_post preview and confirmed. That is a clear when-to-use gate plus the alternative step named, leaving nothing to inference for a high-stakes publish action.

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