Skip to main content
Glama
mambalabsdev

mcp-gtm-suite

by mambalabsdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Fingerprint Outbound Infrastructure

fingerprint_outbound_infrastructure
Idempotent

Determine if a company runs cold email outbound and on what stack. Analyzes lookalike sending domains, inbox providers, SPF, DKIM, and DMARC from public DNS.

Instructions

Given a company domain, determine whether that company runs cold email outbound and on what stack. Returns a runs_outbound verdict of program (a deliberate cold outbound setup), light (one weak signal), none, or unknown, with the evidence behind it. The strongest signal is the lookalike sending domains a real program leaves behind: domains like getcompany.com or company-mail.com that carry their own mail and redirect back to the primary site. Also returns the inbox provider (Google Workspace, Microsoft 365 and others) for the primary domain and each sending domain, any detected sending platform (Outreach, Salesloft, Lemlist, Instantly, Smartlead, Apollo and more), registration clusters showing sending domains bought on the same day, cold email infrastructure vendors, and SPF, DKIM and DMARC posture. Sending platform recall is partial by design: sequencers that connect over OAuth to a customer's own mailbox leave no DNS trace, so an empty sending_platforms means little while a populated one is solid. Public DNS and HTTP redirects only. Returns flat, Clay-ready JSON. Reads public data and writes nothing; requires an APIFY_TOKEN and consumes Apify credits per domain analyzed.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNoCompany domain to analyze, without https or www, e.g. smartlead.ai.
domainsNoBatch mode: several company domains analyzed in one call. Takes precedence over domain.
skipCacheNoForce a fresh analysis and ignore the 7 day result cache.
dns_timeout_msNoPer-DNS-lookup timeout in milliseconds.
max_charge_usdNoOptional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.
request_timeout_msNoPer-HTTP-request timeout in milliseconds.
check_deliverabilityNoAdd a blacklist check and a 0-100 health score by running the separate Domain Deliverability Checker actor, which bills its own per-domain rate on top of this one. Default false. SPF, DKIM and DMARC are read from DNS either way.
scan_sending_domainsNoScan for lookalike sending domains. Default true. The strongest signal and the slowest step; turning it off caps the verdict at what platform and deliverability signals alone can prove.
sending_domain_depthNodeep (default) checks .com, .co, .io, .net and .org. standard drops .net and .org.
max_sending_domain_probesNoCap on how many candidate sending domains are probed per company. Lower it to bound run time on companies with many lookalike domains.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.14.0
    • addedInput schema / properties / max_charge_usd
      Added value: +{
+  "description": "Optional spending cap for this call, in USD, passed to the actor as max_charge_usd. The run stops before any charge that would take it past this amount and keeps every row already charged. Leave empty to rely only on the maximum charge per run set on your Apify account.",
+  "minimum": 0,
+  "type": "number"
+}
  2. Addedv1.1.1

TDQS

A4.2/5.0
Behavior5/5

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

Despite readOnlyHint=false, the description discloses unusually rich behavior beyond the annotations: it requires an APIFY_TOKEN, consumes Apify credits per domain, uses public DNS/HTTP redirects only, and explicitly warns that sending-platform recall is partial by design (OAuth-connected sequencers leave no DNS trace), so an empty list means little. That is exactly the kind of caveat an agent needs.

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 purpose and verdict semantics are front-loaded, and the dense enumeration of returned fields earns its place because there is no output schema. It is a long single block of prose, which costs some readability, but there is little genuinely redundant content.

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?

With no output schema, the description carries the full burden of explaining returns and does so thoroughly: the runs_outbound verdict values and their meanings, inbox providers, sending platforms, registration clusters, vendors, and SPF/DKIM/DMARC posture, plus auth and cost requirements. Nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% with 10 well-documented parameters, so the schema does the heavy lifting and the baseline is 3. The description adds no syntax or defaulting guidance for individual parameters (it never mentions domain vs domains precedence, skipCache, or timeouts), so it does not exceed the schema.

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 opens with a specific verb+resource+scope: 'Given a company domain, determine whether that company runs cold email outbound and on what stack.' That is far more precise than the sibling detect_gtm_tech_stack or detect_ai_tooling, and an agent can tell instantly what this tool is for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage context is implied clearly (domain-based cold-outbound fingerprinting), but there is no explicit when-to-use/when-not guidance and no comparison to adjacent siblings such as detect_gtm_tech_stack, which an agent might reasonably confuse with 'on what stack' detection.

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

Deploy Server

Other Tools