Skip to main content
Glama
Sign In

Emailchaser

by com.emailchaser
OverviewDiscussionsAdmin

Autopilot: start a run

start_autopilot_run

Starts an autopilot run for a company website: the AI builds an ICP, writes a sequence and checks that prospects match, then STOPS at an approval gate. Nothing is revealed, charged or sent and no sending accounts are bought until the run is approved; approval then reveals the first batch at 1 credit ($0.033 at list) per prospect, up to targetProspects and at most 2,000. The call is refused when the wallet cannot cover that batch. When budgetUsd is given, the sized budget plan is snapshotted on the run and returned in this response, the only response that carries it, with credits valued at list, and targetProspects defaults to the plan's monthly prospects. Without budgetUsd the run can never buy sending accounts, so the workspace needs one connected before approval or the run fails. Requires an active subscription (any plan).

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": {
      "website": "<website>"
    },
    "name": "start_autopilot_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
websiteYesThe company website to seed the run from, e.g. https://acme.com
budgetUsdNoMonthly budget in US dollars; sizes a plan that is snapshotted on the run
replyModeNoHow inbound replies are handled: off, draft (default: AI drafts a reply for a human to send), approve, or auto. auto SENDS AI replies to interested prospects without review, so only pass it when the user has asked for that explicitly
maxMailboxesNoCap on the budget plan's mailboxes. 0 means no cap
targetProspectsNoHow many prospects approval reveals first, at 1 credit ($0.033 at list) each (at most 2,000 in one batch). Defaults to the budget plan's monthly prospects when budgetUsd is given, else 50

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. Changed1 schema field changed
    • changedInput schema / properties / targetProspects / description
      Previous value: -"How many prospects approval reveals first, at 5 credits ($0.40 at list) each (at most 2,000 in one batch). Defaults to the budget plan's monthly prospects when budgetUsd is given, else 50"New value: +"How many prospects approval reveals first, at 1 credit ($0.033 at list) each (at most 2,000 in one batch). Defaults to the budget plan's monthly prospects when budgetUsd is given, else 50"
  3. Changed1 schema field changed
    • changedInput schema / properties / targetProspects / description
      Previous value: -"How many prospects to reveal, at 5 credits ($0.40 at list) each, before asking for approval (at most 2,000 in one batch). Defaults to the budget plan's monthly prospects when budgetUsd is given, else 50"New value: +"How many prospects approval reveals first, at 5 credits ($0.40 at list) each (at most 2,000 in one batch). Defaults to the budget plan's monthly prospects when budgetUsd is given, else 50"
  4. Changed1 schema field changed
    • changedInput schema / properties / targetProspects / description
      Previous value: -"How many prospects to source before asking for approval. Defaults to the budget plan's capacity when budgetUsd is given, else the runner default"New value: +"How many prospects to reveal, at 5 credits ($0.40 at list) each, before asking for approval (at most 2,000 in one batch). Defaults to the budget plan's monthly prospects when budgetUsd is given, else 50"
  5. First observed

TDQS

A4.5/5.0
Behavior5/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true): it discloses that nothing is revealed, charged, sent, or bought before approval, the credit cost and per-batch ceiling of 2,000 prospects, the refusal when the wallet is short, and that the budget plan snapshot is returned only in this response. That is exactly the cost/side-effect/irreversibility context an agent needs before triggering a billable write.

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 purpose and the approval gate, then progressively adds cost, budget, and prerequisite detail — a sensible order. It is dense but nearly every clause carries decision-relevant information, with minor redundancy in the repeated credit valuation ('1 credit ($0.033 at list)') and 'at list' phrasing.

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 billable, multi-stage kickoff tool with no output schema, the description covers cost, caps, failure modes, subscription prerequisites, and that this response uniquely carries the budget snapshot. Return fields beyond the plan (e.g., the new run's identifier for later get/approve calls) are not named, a small gap for an agent that must chain to approve_autopilot_run.

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 100%, so baseline is 3, but the description adds cross-parameter meaning the schema cannot: targetProspects defaults to the plan's monthly prospects when budgetUsd is given and to 50 otherwise, budgetUsd snapshots a plan onto the run, and the 2,000 cap applies to the first revealed batch. Only replyMode goes undiscussed in the prose, which keeps it just below the top score.

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 ('Starts an autopilot run for a company website') and immediately scopes the behavior: the AI builds an ICP, writes a sequence, checks prospects, then STOPS at an approval gate. That gate sentence implicitly separates it from approve_autopilot_run and the other run-lifecycle siblings, so an agent can tell what this tool does and does not do.

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 concrete preconditions rather than vague guidance: an active subscription is required, the wallet must cover the first batch, and without budgetUsd the workspace needs a connected sending account before approval or the run fails. What it lacks is an explicit statement of the alternative path (e.g., use plan_autopilot to preview first, or approve_autopilot_run as the next step), which is left to inference from the approval-gate wording.

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