stack-and-dns-mcp

Start Bulk Domain Check

start_bulk_check

Queue background email, technology stack, or combined audit checks for up to 1,000 domains and get a job ID immediately; poll progress and paged results.

Instructions

Queue a lead list for background checking: email (deliverability), tech (technology stack) or audit (both) for up to 1000 domains. Returns a job id immediately; poll get_bulk_check for progress and paged results. Every scan is also recorded for domain_history. Charged when the job is accepted, per accepted domain, at the matching single-domain tool's price (email 1, tech 1, audit 2 credits, or one daily-quota unit per domain on plan keys); items that fail for retryable reasons or are cancelled are refunded when the job finishes; the charge shows in job.creditsCharged or job.quotaUnitsCharged, not in billing.creditsCharged. Invalid and duplicate inputs are never charged, but a list with more invalid or duplicate entries than max(100, accepted domains) is refused with INVALID_ARGUMENT.

Input Schema

Name	Required	Description	Default
`check`	Yes	email = verify_email_infrastructure, tech = inspect_tech_stack, audit = comprehensive_audit, for every domain.
`domains`	Yes	Domains, URLs or email addresses. Duplicates (by site) and invalid entries are skipped and never charged; a list with more invalid or duplicate entries than max(100, accepted domains) is refused with INVALID_ARGUMENT. At most 1000 distinct domains per job, in at most 2000 entries; a list over either limit (up to 50000 entries) is refused with LIMIT_EXCEEDED (details.maxDomains).

Output Schema

Name	Required	Description
`job`	Yes
`next`	Yes
`billing`	Yes
`skipped`	Yes	The first 100 skipped inputs.
`skippedTotal`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.1Nov 4, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the annotations (readOnlyHint=false, idempotentHint=false, openWorldHint=true) by disclosing asynchronous semantics (returns a job id immediately), side effects (every scan recorded in domain_history), billing timing and per-mode pricing, refund behavior for retryable failures and cancellations, where the charge surfaces (job.creditsCharged vs billing.creditsCharged), and the refusal threshold for invalid/duplicate-heavy lists.

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 action and mode, followed by the async contract, then billing, then edge cases – a sensible order. It is dense but the length is justified by the tool's complexity; the invalid/duplicate sentence overlaps with the schema description and could be trimmed.

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?

Despite an output schema existing, the description still supplies the crucial lifecycle information (job id now, results later via get_bulk_check) and full cost/refund accounting. For a charged, async, non-idempotent mutation, an agent has everything needed to call it correctly and explain the outcome to a user.

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 already 100%, so the enum meaning and the duplicate/limit rules are documented there and the description partly repeats them. It does add value beyond the schema by attaching cost semantics to each check mode (1, 1, 2 credits, or one daily-quota unit) and by tying 'audit' to running both checks per domain.

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: 'Queue a lead list for background checking' with the three concrete modes (email, tech, audit) and the domain cap. It also disambiguates from the single-domain siblings by mapping each mode to verify_email_infrastructure, inspect_tech_stack, or comprehensive_audit.

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 clear usage context: this is the batch entry point for up to 1000 domains, and it explicitly routes the agent to get_bulk_check for progress and paged results. What is missing is an explicit inverse rule (e.g. 'use verify_email_infrastructure for a single domain'), though the mode-to-sibling mapping implies it.

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

Deploy Server