Skip to main content
Glama

rankparse-mcp

by io.github.abhibavishi
OverviewDiscussionsAdmin

outreach_add_contacts

Add contacts with per-contact email copy to a campaign (max 100 per call, 500 per campaign, one contact per domain). Works on a draft campaign AND on an already-launched one, which is how you top a live campaign up with fresh prospects. Each contact needs a researched, real email address (never guess addresses) plus a personalized subject and plain-text body (subject ≤500 chars, body ≤10,000). Write like a human: plain punctuation, and NEVER use em-dashes in subjects or bodies. Subjects must be 2-5 words that read like a note from a colleague and reference their content (e.g. "your AI tools guide"): never sales words like exclusive, lifetime, revenue, or deal. Internationalized (non-ASCII) domains must be given in punycode (xn--) form. Returns how many were added and which were skipped (invalid email, duplicate domain/email, copy too long, campaign full, already_contacted = this person was emailed in an earlier campaign). Contacts added to a launched campaign sit inert until you call outreach_launch_campaign again. A contact already in the campaign is skipped as duplicate_email or duplicate_domain and its copy is NOT changed: to rewrite the copy of existing contacts use outreach_update_contacts, do not create a new campaign.

Input Schema

NameRequiredDescriptionDefault
contactsYesContacts with their personalized copy
campaign_idYesCampaign id from outreach_create_campaign

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / contacts / items / properties / domain_authority
      Added value: +{
+  "description": "Domain authority 0-100 if you already looked it up, for sorting and stats. Out-of-range values are stored as unknown rather than rejected.",
+  "type": "number"
+}
  2. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: hard caps (100 per call, 500 per campaign, one contact per domain), field limits, the punycode requirement, the launched-campaign inertness rule, and an enumeration of skip reasons including the semantics of already_contacted. The duplicate-email/duplicate-domain no-overwrite behavior is exactly the kind of side effect an agent needs before calling.

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?

Dense but front-loaded: the action and the core limits come first, then copy-writing rules, then return/skip semantics. It is long and some parentheticals could be trimmed, but nearly every sentence carries a constraint the agent cannot get elsewhere.

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?

No output schema exists, yet the description states what is returned (added count plus skipped reasons with their meanings). Combined with limits and validation rules, an agent has everything needed to call this correctly and interpret the result.

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% with per-field descriptions, so the baseline is 3; the description earns above that by adding real constraints absent from the schema (subject ≤500, body ≤10,000, one contact per domain, punycode form, subject style rules). It does not mention the optional name or domain_authority fields, so it isn't exhaustive.

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 ('Add contacts ... to a campaign') and crisply delimits it from outreach_update_contacts and outreach_create_campaign. An agent can distinguish it from all siblings 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 Guidelines5/5

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

Explicitly covers both usage contexts ('works on a draft campaign AND on an already-launched one') and names the alternative for the adjacent task ('to rewrite the copy of existing contacts use outreach_update_contacts, do not create a new campaign'). This is a clear when-to-use / when-not-to-use statement.

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

All rankparse-mcp 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