AfterLaunch

Report a job

report_job

Destructive

Report a claimed attempt with its exact attempt_id: running; needs_input with one question for your user; shipped with the live published_url, or planned_url once merged (we check it); ready_for_review with prepared_content, or asset_url when your user must post it or when it is the pull request you opened; failed with fail_reason. Ready_for_review can be reported again, improved, until your user uses it. If you cannot read the whole thread, say so and ask your user for a screenshot. Free; requires the 'act' scope.

Input Schema

TableJSON Schema

Name	Required	Description
`state`	Yes
`job_id`	Yes	Job id (uuid), from list_queue.
`question`	No	Required with 'needs_input'.
`asset_url`	No	URL of the prepared asset. This does not claim publication.
`attempt_id`	Yes	Exact attempt id; null only when list_queue identified a legacy job.
`fail_reason`	No	Required with 'failed': what stopped you.
`planned_url`	No	With 'shipped': a merged own-site change's page; we check it, it ships within two days.
`receipt_url`	No	A permalink to the proof.
`session_url`	No	Optional. The launch already gave your user the link to this session; pass it only when you opened this session yourself and can see its address.
`published_url`	No	With 'shipped': the live https address.
`site_repository`	No	Optional, for a routine working a site move: the repository it can write to, as owner/name, or null if it has none. Omit it to say nothing.
`prepared_content`	No	Prepared result body for ready_for_review.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

changedInput schema / properties / planned_url / description

Previous value: -"With 'shipped': an own-site page's future address."New value: +"With 'shipped': a merged own-site change's page; we check it, it ships within two days."

Changed1 schema field changedOct 13, 2026

addedInput schema / properties / site_repository

Added value: +{
+  "description": "Optional, for a routine working a site move: the repository it can write to, as owner/name, or null if it has none. Omit it to say nothing.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed1 schema field changedOct 13, 2026

changedInput schema / properties / session_url / description

Previous value: -"Your own session URL, if you have one."New value: +"Optional. The launch already gave your user the link to this session; pass it only when you opened this session yourself and can see its address."

Changed4 schema fields changedOct 9, 2026

addedInput schema / properties / planned_url

Added value: +{
+  "description": "With 'shipped': an own-site page's future address.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / published_url

Added value: +{
+  "description": "With 'shipped': the live https address.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / question

Added value: +{
+  "description": "Required with 'needs_input'.",
+  "maxLength": 500,
+  "type": "string"
+}

changedInput schema / properties / state / enum

Previous value: -[
-  "running",
-  "ready_for_review",
-  "shipped",
-  "failed"
-]New value: +[
+  "running",
+  "needs_input",
+  "ready_for_review",
+  "shipped",
+  "failed"
+]

Changed5 schema fields changedSep 8, 2026

changedInput schema / properties / asset_url / description

Previous value: -"The live URL of what was published."New value: +"URL of the prepared asset. This does not claim publication."

addedInput schema / properties / attempt_id

Added value: +{
+  "description": "Exact attempt id; null only when list_queue identified a legacy job.",
+  "type": [
+    "string",
+    "null"
+  ]
+}

addedInput schema / properties / prepared_content

Added value: +{
+  "description": "Prepared result body for ready_for_review.",
+  "maxLength": 20000,
+  "type": "string"
+}

changedInput schema / properties / state / enum

Previous value: -[
-  "running",
-  "shipped",
-  "failed"
-]New value: +[
+  "running",
+  "ready_for_review",
+  "shipped",
+  "failed"
+]

changedInput schema / required

Previous value: -[
-  "job_id",
-  "state"
-]New value: +[
+  "job_id",
+  "attempt_id",
+  "state"
+]

Changed1 schema field changedAug 30, 2026

addedInput schema / properties / session_url

Added value: +{
+  "description": "Your own session URL, if you have one.",
+  "type": "string"
+}

AddedAug 30, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations declare this is a write (readOnlyHint=false, destructiveHint=true), and the description adds value beyond them: the 'act' scope requirement, the fact that planned_url/published_url are checked by the system, and that ready_for_review is repeatable until the user consumes it. It does not explain what the destructiveHint actually destroys, which keeps it short of 5.

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

Conciseness4/5

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

Front-loads the core verb and the attempt_id requirement, then walks the state list. It is dense and semicolon-chained but nearly every clause carries a distinct constraint; the thread/screenshot aside is slightly tangential but still operational.

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

Completeness4/5

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

For a 12-parameter write tool with no output schema, the description covers state semantics, required companions, auth scope, and verification behavior. The main omission is any statement of what the call returns or what the destructive action affects.

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

Parameters4/5

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

Schema coverage is already 92%, so the baseline is 3, but the description goes further by binding parameters to states ('shipped with the live published_url, or planned_url once merged') and clarifying asset_url's meaning ('when your user must post it or when it is the pull request you opened'). That adds real semantics beyond the schema text.

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

Purpose4/5

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

States a specific verb and resource ('Report a claimed attempt with its exact attempt_id') and enumerates the state transitions it can record. It clearly distinguishes itself from read-side siblings like list_queue/get_loop_status, 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.

Usage Guidelines3/5

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

The state-by-state enumeration effectively tells the agent which payload each mode requires, which is real usage guidance. However there is no explicit when-to-use/when-not framing or routing to alternatives (e.g., set_output_status, ship_move), so the guidance is implied rather than stated.

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

All AfterLaunch tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?