Loading ToolBench
Outbound Engine MCP for AI agents and creators. One cold-outreach engine, any target: brand deals, UGC, newsletter sponsorships, jobs, podcasts. HOOK/BRIDGE/SOFT-ASK structuring, message auditing, 5-step follow-up ladder, reply playbook, 3-option pricing menu, red-flag detection.
Server has 6 well-named tools with clear, domain-specific descriptions (avg 180 chars). All tools have input schemas with enums and type definitions. However, output schemas are NOT documented in the source code, only descriptions of what each tool returns in natural language. No error handling guidance, no recovery patterns, and no tool annotations (readOnlyHint, destructiveHint). Parameter descriptions are present but minimal. Tools are READ_ONLY by design, which is good for safety, but this is not formally declared via annotations.
Takes a reply from a prospect and classifies it into one of 5 categories: price_question, interested, not_now, no_budget, or exposure_offer. For each category, returns: (1) meaning — what the reply signals; (2) next_move — the exact move to make; (3) reply_shape — a template for your response; (4) trap_to_avoid — the mistake people make here.
Takes a base price and builds a 3-option pricing menu: (1) Stripped (lowest scope, lowest price), (2) Standard (your default), (3) Premium (highest scope, highest price). Input: base_price (the standard option price), scope_description (what the standard scope includes). Output: three options with price, scope, and positioning for each.
Scans a cold message for red flags that kill reply rates. Checks for: (1) Generic language ('I love your brand', 'I help businesses grow'); (2) Desperation signals (long copy, multiple asks, urgency language); (3) Mismatched proof (proof that does not apply to the target); (4) Closed asks (asking for a meeting, a call, a rate, a hire — instead of permission to send something); (5) No signal (no specific research visible). Output: list of flags found, severity (high/medium/low), and a fix for each.
Returns the next step in the 5-step follow-up ladder. Input: the current step number (1-5). Output: the day to send, the move to make, a template shape, and the rule to follow. The ladder is: (1) Bump + new angle (day 3), (2) Give value, no ask (day 7), (3) New proof (day 12), (4) Soft close (day 18), (5) The break-up (day 25).
Output schemas not documented in code. Tool descriptions state what is returned (e.g., 'structured JSON with pass/fail on each, violations listed, and a rewrite suggestion') but no formal JSON Schema for response objects. LLMs cannot plan downstream tool calls or extract fields reliably without documented output structure.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 6 tools are READ_ONLY and idempotent by design, but this is not formally declared in the tool definition. Agents cannot infer safety properties without explicit annotations.
No error handling or recovery guidance. Tools have no documented error cases, validation rules, or actionable error messages. If a tool receives invalid input (e.g., target_type not in enum), the response is not shown in source code.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Returns the target pack for a given target type. A target pack contains: (1) who_to_pitch — the right person to contact; (2) signal_to_research — what to look for before pitching; (3) proof_to_lead_with — the type of proof that converts; (4) soft_ask_object — what to offer in the ask; (5) common_mistakes — the 3-5 errors people make for this target. Targets: brand_deal, ugc, newsletter_sponsorship, job, podcast, client_work.
Takes a draft cold message and a target type (brand_deal, ugc, newsletter_sponsorship, job, podcast, client_work). Returns: (1) HOOK analysis — does it reference a specific signal? (2) BRIDGE analysis — does it lead with proof? (3) SOFT_ASK analysis — is it a conversation ask, not a close? (4) Length check — under 90 words? (5) Red flags — common mistakes for that target type. Output: structured JSON with pass/fail on each, violations listed, and a rewrite suggestion if needed.
Parameter descriptions are minimal (avg 20-40 chars). E.g., 'The cold message draft to analyze' and 'The target type to retrieve the pack for' lack context on format, constraints, or when to use each tool. Descriptions should be 50-200 chars and include usage hints.
No pagination or result limits documented. Tools like get_target_pack and get_followup_step return fixed data, but if tools were extended to return lists (e.g., common_mistakes as an array), no limit or pagination guidance is present.