Emailchaser

Buy credits (charges real money)

purchase_credits

Destructive

SPENDS REAL MONEY. Immediately charges the workspace's saved default card (the one behind the active subscription), off-session, with no confirmation step beyond this call — every successful call is a new charge. Buys 1,000 to 10,000 prospect credits at the tiered list price: $33/1k · $20/1k from 5k. The server prices the charge, so treat this as the list price and not a quote. Errors carry a machine-readable code: billing_required and payment_failed mean no money moved (fix billing or the card, then retry); credits_free means this workspace's credits are free, so nothing was charged and there is nothing to buy; temporarily_unavailable means the purchase stopped before any charge, so it is safe to retry shortly; purchase_incomplete means the card WAS charged but crediting failed — do NOT retry, support is already notified; purchase_unconfirmed means the outcome is unknown or the purchase completed without a balance to report: a stripe_topup entry in the credit ledger means the card was charged, so retrying before the outcome is known can charge twice. After a timeout or a dropped connection the outcome is equally unknown, so do not call this again until it is known.

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": {
      "credits": "<credits>"
    },
    "name": "purchase_credits"
  }
}

Input Schema

Name	Required	Description	Default
`credits`	Yes	How many prospect credits to buy (1,000 to 10,000)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 29, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

Changed2 schema fields changedSep 15, 2026

changedInput schema / properties / credits / description

Previous value: -"How many prospect credits to buy (1,000 to 100,000)"New value: +"How many prospect credits to buy (1,000 to 10,000)"

changedInput schema / properties / credits / maximum
```
Previous value: -100000New value: +10000
```

First observedSep 12, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations flag destructive/non-idempotent, but the description goes far beyond them: off-session charge against the saved default card, no confirmation step, every successful call is a new charge, server-side pricing, and a full error-code taxonomy with which states moved money.

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 money warning, then effect, pricing, and error semantics in a logical order. It is long and the error-code clause is a dense run-on, but nearly every sentence carries retry-safety information that prevents double charges.

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, non-idempotent, money-moving tool with no output schema, it covers cost, charge mechanics, and the ambiguous-outcome edge cases an agent most needs. The only mild gap is not suggesting a pre-purchase balance check.

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% and the single parameter already documents the 1,000–10,000 bounds, but the description adds the tiered price structure ($33/1k, $20/1k from 5k), which is real decision-relevant meaning the schema lacks.

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?

Opens with a specific verb+resource and an unmistakable stake: 'SPENDS REAL MONEY ... Buys 1,000 to 10,000 prospect credits at the tiered list price.' An agent can tell instantly that this is a paid purchase rather than a balance read like get_credit_balance.

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 strong when-not-to-use conditions: do not retry on purchase_incomplete or purchase_unconfirmed, and do not re-call after a timeout or dropped connection. It never names a sibling alternative (e.g., checking balance first), so it stops short of full routing guidance.

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

All Emailchaser tools Inspect

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

Need Help?