Skip to main content
Glama

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 approve_autopilot_run is called; 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).

Input Schema

TableJSON 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 / 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"
  2. 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"
  3. 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"
  4. First observed

TDQS

A4.6/5.0
Behavior5/5

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

With only openWorldHint and destructiveHint false in annotations, the description carries the behavioral burden and does so thoroughly: no reveal/charge/send until approval, credit pricing and caps, wallet-refusal behavior, budget plan snapshot and response exclusivity, and the no-sending-account implication when budgetUsd is absent. This is the type of side-effect disclosure that annotations do not provide.

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?

The core purpose and approval gate are front-loaded, and the subsequent sentences each add a distinct operational constraint, cost, default, or prerequisite. It is dense rather than concise, and the long clauses could be easier to scan, but no sentence is filler.

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 five-parameter tool with no output schema and only generic annotations, the description covers the invocation flow, side effects, cost model, defaults, failure modes, and response-specific caveats. An agent has enough operational context to call the tool and to decide whether it should call approve_autopilot_run next.

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 description coverage is complete, so the baseline is 3, but the description adds cross-parameter semantics beyond the schema: targetProspects defaults derive from budgetUsd's plan, approval reveals cost 1 credit per prospect up to a 2,000 cap, and wallet coverage is assessed against that batch. These relationships materially affect how an agent should set parameters.

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?

The description states a specific verb and resource ('Starts an autopilot run for a company website') and summarizes the run's lifecycle: build ICP, write sequence, check prospects, then stop at an approval gate. This makes it unmistakable how start_autopilot_run relates to approve_autopilot_run.

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?

It clearly places the tool in the approval-gate flow and names approve_autopilot_run as the next step that reveals and charges for the first batch. It also provides hard usage conditions: refusal when wallet cannot cover the batch and the requirement to have a sending account connected when budgetUsd is omitted. It does not explicitly contrast with plan_autopilot, but the start/approve lifecycle is clear.

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