Skip to main content
Glama

BlackVeil DNS & Email Security Scanner

check_lookalikes

Read-onlyIdempotent

Detect active typosquat and lookalike/homoglyph domains that impersonate your brand and could be used in phishing. Identifies character-substitution and visual-confusion domains registered by attackers. Distinct from check_shadow_domains (TLD variants with auth gaps) and discover_brand_domains (legitimate brand portfolio).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>"
    },
    "name": "check_lookalikes"
  }
}

Input Schema

NameRequiredDescriptionDefault
domainYesDomain, e.g. example.com
formatNoOutput verbosity.
force_refreshNoBypass the cache.

Output Schema

NameRequiredDescriptionDefault
scoreYes
passedYes
partialNo
categoryYes
findingsYes
checkStatusNo
verdictWithheldNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / domain / description
      Previous value: -"Domain to check (e.g., example.com)"New value: +"Domain, e.g. example.com"
    • changedInput schema / properties / force_refresh / description
      Previous value: -"Bypass cache and run a fresh check. Useful after DNS changes."New value: +"Bypass the cache."
    • changedInput schema / properties / format / description
      Previous value: -"Output verbosity. Auto-detected if omitted."New value: +"Output verbosity."
  2. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  3. Changed1 schema field changed
    • addedOutput schema / properties / verdictWithheld
      Added value: +{
      +  "type": "boolean"
      +}
  4. Changed2 schema fields changed
    • addedOutput schema / properties / checkStatus
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / partial
      Added value: +{
      +  "type": "boolean"
      +}
  5. Changed1 schema field changed
    • addedInput schema / properties / force_refresh
      Added value: +{
      +  "description": "Bypass cache and run a fresh check. Useful after DNS changes.",
      +  "type": "boolean"
      +}
  6. 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"
      +}
  7. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the description's added context is what counts: it discloses that only "active" registered attacker domains are reported and that the signal is impersonation/phishing risk rather than passive registration data. It stops short of describing how "active" is determined, scan latency, or the cost/rate profile of an open-world lookup.

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 sentences, each load-bearing: what it finds, who registers them, and how it differs from siblings. The purpose leads, the disambiguation trails, and there is no filler or restatement of the tool name.

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 three-parameter, single-domain read-only check with a full output schema and complete parameter descriptions, the description supplies everything an agent needs: intent, threat model, and sibling disambiguation. Return values and safety semantics are already covered by structured data, so nothing material 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 coverage is 100% and every parameter already carries a description (domain, format enum, force_refresh cache bypass), so the schema does the work. The prose adds no format, validation, or cache-freshness meaning beyond it; the baseline 3 applies.

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 ("Detect ... typosquat and lookalike/homoglyph domains") and narrows the scope to domains that impersonate the user's brand. It explicitly separates itself from the two nearest siblings by naming them and characterizing their domains, so an agent can pick correctly without opening a 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?

The final sentence gives explicit routing: use check_shadow_domains for TLD variants with auth gaps and discover_brand_domains for the legitimate portfolio. That is both a when-to-use and a when-not-to-use statement with named alternatives, which is the strongest form of guidance.

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.