Skip to main content
Glama
Sign In

AfterLaunch

by io.afterlaunch
OverviewDiscussionsAdmin

Accept a growth move

accept_move
Destructive

Accept a move only after the founder says yes or has granted draft ahead. This records one durable preparation attempt and may start the configured worker only when launch_won is true. A repeat never starts another worker. Free; requires the 'act' scope.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "move_id": "<move_id>",
      "target": "<target>"
    },
    "name": "accept_move"
  }
}

Input Schema

NameRequiredDescriptionDefault
noteNo
targetYesagent_pull puts the work in the queue for an AI to claim. share, open, claude_cloud, cursor and codex only record where your user took it; nothing starts.
move_idYesMove id (uuid).
operationNoDefaults to accept. Retry requires expected_attempt_id; use null only with the exact legacy state and updated_at.
expected_attempt_idNoRequired for retry. Pass the exact managed attempt, or null for a legacy job.
expected_legacy_stateNoget_move: prepared_result.legacy_state ?? state.
expected_legacy_updated_atNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / target / description
      Added value: +"agent_pull puts the work in the queue for an AI to claim. share, open, claude_cloud, cursor and codex only record where your user took it; nothing starts."
  2. Changed1 schema field changed
    • addedInput schema / properties / expected_legacy_state / description
      Added value: +"get_move: prepared_result.legacy_state ?? state."
  3. Added

TDQS

A4.1/5.0
Behavior5/5

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

Annotations declare mutation (readOnlyHint=false, destructiveHint=true) but the description adds real value beyond them: it discloses the durable preparation attempt, that a worker starts only when launch_won is true, that repeats never start another worker, that the call is free, and that the 'act' scope is required. That is exactly the side-effect/idempotency/cost/auth context an agent needs before invoking a destructive tool.

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

Conciseness5/5

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

Four short sentences, front-loaded with the gating condition, then side effects, then idempotency, then cost/scope. No redundant restatement of the title or schema.

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 destructive, open-world mutation with seven parameters and no output schema, the description covers preconditions, side effects, repeat semantics, cost, and required scope. It omits only return-value expectations and failure modes, which keeps it just under complete.

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

Parameters3/5

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

Schema coverage is 71%, so the schema already documents target enum meanings, operation, and the expected_* retry guards. The description adds no parameter-level detail beyond the behavioral note about repeats; baseline 3 is appropriate given the schema does the parameter work.

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 ('Accept a move') plus the gating precondition ('only after the founder says yes or has granted draft ahead'), which distinguishes it from proposal/revise siblings in spirit. It does not explicitly name an alternative tool, 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.

Usage Guidelines4/5

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

Gives a clear, exclusive when-to-use condition ('only after the founder says yes or has granted draft ahead') and clarifies repeat-call behavior. No explicit when-not or named alternative tool is given, so it is clear context without exclusions.

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

All AfterLaunch toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources