Skip to main content
Glama

launch_sweep

Idempotent

Start a validated sweep. THIS IS THE ONE CALL THAT SPENDS: it puts the engine to work on every run the search describes, for minutes or hours, and there is no undoing it -- pause_sweep stops further work but does not give back what already ran. So say the run count out loud and get the person's agreement before calling it; a number they never saw is not one they agreed to. It returns immediately with the sweep queued or preparing, NOT with results: the runs land over time and get_sweep says how far along it is. A status of queued means it starts when the account's current sweep finishes, which is the sweep beginning and not a refusal.

[Access: pay 0.25 USDC via x402 (PAYMENT-SIGNATURE header) OR authenticate with an API key. An x402-capable client will auto-pay; API-key clients pay nothing per call.]

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": {
      "experiment_id": "<experiment_id>"
    },
    "name": "launch_sweep"
  }
}

Input Schema

NameRequiredDescriptionDefault
experiment_idYesThe sweep, as create_sweep returned it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare the safety profile (readOnly=false, destructive=false, idempotent=true), so the description rightly carries the operational burden and does: it spends money, it takes minutes to hours, it is partial-irreversible (pause stops future work but not past work), it returns asynchronously with queued/preparing rather than results, and it requires either x402 payment or an API key. That is unusually rich disclosure for a mutation tool.

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-loaded with the highest-stakes fact ('THIS IS THE ONE CALL THAT SPENDS') and organized as spend risk, then return behavior, then auth. Slightly padded by the rhetorical aside 'a number they never saw is not one they agreed to' and the em-dash cadence, but no sentence is redundant with another.

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

Completeness5/5

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 covers exactly what would otherwise be missing: the return is a queued/preparing acknowledgment rather than results, progress must be polled via get_sweep, and the payment/API-key access paths are spelled out. Nothing an agent needs to call this correctly is absent.

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 100% and the single parameter is already documented ('The sweep, as create_sweep returned it'), so the baseline is 3. The description adds indirect context by implying the sweep's run count was fixed earlier by create_sweep/size_sweep, but it adds no new syntax or formatting meaning for experiment_id itself.

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

Purpose5/5

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

States a specific verb and resource ('Start a validated sweep') and immediately distinguishes it from the siblings that share its object: create_sweep builds the sweep, this one launches it, and get_sweep/pause_sweep monitor and halt it. An agent can pick this apart from the other sweep tools without opening a schema.

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

Usage Guidelines5/5

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

Explicitly gates invocation on a human-visible run count and explicit agreement, and names the alternatives: get_sweep for progress, pause_sweep for stopping. It also pre-empts a misread ('queued means it starts when the account's current sweep finishes, not a refusal'), which is exactly the kind of alternative-interpretation guidance that prevents wrong calls.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.