Skip to main content
Glama
Sign In

Emailchaser

by com.emailchaser
OverviewDiscussionsAdmin

Autopilot: approve a run

approve_autopilot_run
Destructive

Approves an autopilot run that is awaiting approval — the one human gate in the flow. CAN SPEND REAL MONEY: approval first reveals the run's prospects at 1 credit ($0.033 at list) each, then, if the workspace has no connected sending account, places one done-for-you order sized from the plan snapshotted at start, at most 10 .com domains and at most six mailboxes per domain, never more mailboxes than the plan, charged at the prices in effect when the order is placed. So the plan's mailbox and domain counts are a ceiling and its dollar figures an estimate, not an exact quote. No credits are bought, but the reveal and later top-ups spend the wallet's credits. If a sending account is already connected, no infrastructure is bought; a run started without budgetUsd and with no connected account fails. Show the user the plan returned when the run was started before calling this. Nothing is revealed, bought or sent before this call; after it, sending starts without further confirmation.

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": {
      "id": "<id>"
    },
    "name": "approve_autopilot_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe numeric autopilot run ID (from list_autopilot_runs)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already flag destructive=true and openWorldHint=true, but the description goes well beyond them: it discloses that approval spends credits on prospect reveals at 1 credit each, may place a done-for-you order, enumerates the caps (10 .com domains, six mailboxes per domain, never more mailboxes than the plan), and warns that prices are those in effect at order time so the plan's dollar figures are an estimate. It also clarifies sequencing ('Nothing is revealed, bought or sent before this call; after it, sending starts without further confirmation'), which is exactly the irreversibility an agent needs.

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 action and the 'CAN SPEND REAL MONEY' warning, and every clause carries information about cost or side effects. The middle sentence is a long chained construction that could be split for readability, but nothing is padding.

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?

For a one-parameter, high-stakes mutation with no output schema, the description covers cost, caps, failure modes, and what does and does not happen on either side of the call. An agent has everything needed to warn the user and invoke it correctly.

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?

There is only one parameter and schema coverage is 100%, with the schema itself noting the ID comes from list_autopilot_runs. The description adds no further meaning about the id (e.g., what states are valid or what happens if it is not awaiting approval), so the schema does the work and the baseline applies.

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?

Specific verb and resource: 'Approves an autopilot run that is awaiting approval', and the phrase 'the one human gate in the flow' separates it from sibling controls like pause_autopilot_run, resume_autopilot_run and kill_autopilot_run. An agent can identify both the action and the run state it applies to 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.

Usage Guidelines4/5

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

Gives an explicit precondition ('Show the user the plan returned when the run was started before calling this') and states failure conditions (a run started without budgetUsd and with no connected account fails) plus a branch where no infrastructure is bought. It does not name a sibling alternative for the case where the user declines approval, so it stops short of full when-not guidance.

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

All Emailchaser 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