Skip to main content
Glama

BlackVeil DNS & Email Security Scanner

brand_audit_batch_start

Enqueue an async brand audit across up to 50 target domains with optional standard/deep discovery depth, brand aliases, and caller-supplied candidate domains. Returns { auditId, queuedAt, targetCount, etaSeconds } immediately; poll with brand_audit_status and fetch results with brand_audit_get_report once complete. Each target consumes 1 unit of the monthly BRAND_AUDIT_QUOTAS budget.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
viewNoOutput view mode. 'registrar_complement' produces a registrar-complement payload; requires enterprise tier. Default 'standard'.
depthNoDiscovery depth. standard is default; deep expands candidate seeding and enrichment fanout.
formatNoInline output mode. Defaults to "both".
domainsYesDomains to audit (max 50 per batch). Duplicates are merged.
planner_modeNoPlanner mode for staged discovery fanout. observe emits metrics; enforce applies candidate-backed signal caps.
brand_aliasesNoOptional public brand aliases to seed, such as product or legal-entity labels.
discovery_modeNoBrand-discovery pipeline mode. classic = legacy sweep; tiered = tenant/graph/evidence wrappers first (BlackVeil-internal).
min_confidenceNoDrop candidates whose combined confidence falls below this threshold (0-1, default 0.5).
candidate_domainsNoOptional candidate domains supplied by the caller for corroboration.
ownership_verifiedNoCaller attests that the target domains are owned or authorized for scanning. Required when discovery_mode is "tiered" and the caller is not an enterprise/owner/partner principal.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
scoreYes
passedYes
partialNo
categoryYes
findingsYes
checkStatusNo
verdictWithheldNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedOutput schema / properties / verdictWithheld
      Added value: +{
      +  "type": "boolean"
      +}
  2. Changed2 schema fields changed
    • changedInput schema / properties / view / description
      Previous value: -"Output view mode. 'csc_complement' produces a CSC-tuned payload; requires enterprise tier. Default 'standard'."New value: +"Output view mode. 'registrar_complement' produces a registrar-complement payload; requires enterprise tier. Default 'standard'."
    • changedInput schema / properties / view / enum
      Previous value: -[
      -  "standard",
      -  "csc_complement"
      -]New value: +[
      +  "standard",
      +  "registrar_complement"
      +]
  3. Changed2 schema fields changed
    • addedOutput schema / properties / checkStatus
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / partial
      Added value: +{
      +  "type": "boolean"
      +}
  4. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "additionalProperties": {},
      +  "properties": {
      +    "category": {
      +      "type": "string"
      +    },
      +    "findings": {
      +      "items": {
      +        "additionalProperties": {},
      +        "properties": {},
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "passed": {
      +      "type": "boolean"
      +    },
      +    "score": {
      +      "type": "number"
      +    }
      +  },
      +  "required": [
      +    "category",
      +    "score",
      +    "passed",
      +    "findings"
      +  ],
      +  "type": "object"
      +}
  5. Changed1 schema field changed
    • addedInput schema / properties / ownership_verified
      Added value: +{
      +  "description": "Caller attests that the target domains are owned or authorized for scanning. Required when discovery_mode is \"tiered\" and the caller is not an enterprise/owner/partner principal.",
      +  "type": "boolean"
      +}
  6. Changed1 schema field changed
    • addedInput schema / properties / view
      Added value: +{
      +  "description": "Output view mode. 'csc_complement' produces a CSC-tuned payload; requires enterprise tier. Default 'standard'.",
      +  "enum": [
      +    "standard",
      +    "csc_complement"
      +  ],
      +  "type": "string"
      +}
  7. Changed1 schema field changed
    • addedInput schema / properties / discovery_mode
      Added value: +{
      +  "description": "Brand-discovery pipeline mode. classic = legacy sweep; tiered = tenant/graph/evidence wrappers first (BlackVeil-internal).",
      +  "enum": [
      +    "classic",
      +    "tiered"
      +  ],
      +  "type": "string"
      +}
  8. Changed1 schema field changed
    • addedInput schema / properties / planner_mode
      Added value: +{
      +  "description": "Planner mode for staged discovery fanout. observe emits metrics; enforce applies candidate-backed signal caps.",
      +  "enum": [
      +    "off",
      +    "observe",
      +    "enforce"
      +  ],
      +  "type": "string"
      +}
  9. Changed3 schema fields changed
    • addedInput schema / properties / brand_aliases
      Added value: +{
      +  "description": "Optional public brand aliases to seed, such as product or legal-entity labels.",
      +  "items": {
      +    "maxLength": 64,
      +    "minLength": 2,
      +    "type": "string"
      +  },
      +  "maxItems": 20,
      +  "type": "array"
      +}
    • addedInput schema / properties / candidate_domains
      Added value: +{
      +  "description": "Optional candidate domains supplied by the caller for corroboration.",
      +  "items": {
      +    "maxLength": 253,
      +    "minLength": 1,
      +    "type": "string"
      +  },
      +  "maxItems": 250,
      +  "type": "array"
      +}
    • addedInput schema / properties / depth
      Added value: +{
      +  "description": "Discovery depth. standard is default; deep expands candidate seeding and enrichment fanout.",
      +  "enum": [
      +    "standard",
      +    "deep"
      +  ],
      +  "type": "string"
      +}
  10. Added

TDQS

A4.3/5.0
Behavior4/5

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

Annotations cover safety (readOnlyHint=false, destructiveHint=false, openWorldHint=true, idempotentHint=false), and the description adds genuinely useful behavior beyond them: the call is async and returns immediately, results must be polled, and each target consumes 1 unit of the monthly BRAND_AUDIT_QUOTAS budget. That quota cost is exactly the kind of context 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences: what it does and its limits, what it returns, how to follow up, and what it costs. Front-loaded with the action and scope, with zero filler.

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 10-parameter async job-starter with a full output schema, the description covers everything an agent needs: scope limits, async semantics, the follow-up tool chain, and quota impact. Return-value details are correctly left to the output schema.

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%, so all 10 parameters are already documented in the schema, including enums for depth, discovery_mode, and view. The description names a few of them (discovery depth, brand aliases, candidate domains) and repeats the 50-domain cap, adding marginal value over the structured data. Baseline 3 is appropriate.

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 ('Enqueue an async brand audit') plus scope (up to 50 target domains), which cleanly separates it from brand_audit_single and the status/report siblings. An agent can identify the tool 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 Guidelines4/5

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

Explicitly routes the agent through the workflow: poll with brand_audit_status, fetch results with brand_audit_get_report once complete. It does not explicitly contrast with brand_audit_single, but the 'batch/up to 50 domains' framing makes the choice obvious.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.