Critical Risk →

brand_match

Brand conflict and trademark risk detection workflow. Call when a user wants to check whether a domain name carries brand-related risks before registering or purchasing it. When to use: user asks 'is this domain safe to register?', wants to assess UDRP risk before purchase, or needs trademark con...

Part of the DomainKits server.

brand_match can permanently delete data in DomainKits, with no limits today. PolicyLayer puts allow, deny, and rate-limit rules on every call. Live in minutes.

SECURE DOMAINKITS →

Free to start. No card required.

AI agents may call brand_match to permanently remove or destroy resources in DomainKits. Without a policy, an autonomous agent could delete critical data in a loop with no way to undo the damage. PolicyLayer blocks destructive tools by default and requires explicit human approval before enabling them.

Without a policy, an AI agent could call brand_match in a loop, permanently destroying resources in DomainKits. There is no undo for destructive operations. PolicyLayer blocks this tool by default and only allows it when a human explicitly approves the action.

Destructive tools permanently remove data. Block by default. Only enable with explicit approval workflows.

policy.json
{
  "version": "1",
  "default": "deny",
  "hide": [
    "brand_match"
  ]
}

See the full DomainKits policy for all 38 tools.

Get this rule live on your own DomainKits server in minutes. PolicyLayer enforces it on every call, before it runs.

ENFORCE ON MY DOMAINKITS →

View all 38 tools →

These attack patterns abuse exactly the kind of access brand_match gives an agent. Each links to the full case and the policy that stops it:

Browse the full MCP Attack Database →

Every attack above starts with a tool call. PolicyLayer checks each one against your policy first, so brand_match only ever does what you allow.

SECURE DOMAINKITS →

Other destructive tools across the catalogue. The same approach applies to each: deny by default, or require human approval.

What does the brand_match tool do? +

Brand conflict and trademark risk detection workflow. Call when a user wants to check whether a domain name carries brand-related risks before registering or purchasing it. When to use: user asks 'is this domain safe to register?', wants to assess UDRP risk before purchase, or needs trademark conflict checking as a follow-up from name_advisor or analyze. Do NOT use for general technical analysis (use analyze), domain name brainstorming (use name_advisor), or DNS/registration checks only (use dns, whois). Workflow: 1. Extract the prefix from the domain (e.g., nicefloor.com → nicefloor). If the prefix contains a well-known brand name (google, apple, amazon, microsoft, etc.), immediately warn the user about high UDRP risk before proceeding. Ask the user about their intent: are they assessing risk before registration, or holding the domain and looking for potential buyers? This determines the framing of the analysis. Do NOT call any tools before the user responds. 2. After the user responds, gather data in parallel: - web_search '[prefix] company' to discover existing commercial use — note founding year, business scale, industry, and whether the company actively uses this keyword as a brand. - tld_check to see how many TLDs have this prefix registered. - If tld_check shows high registration, whois the .com/.net/.org variants to check if the same registrar holds multiple TLDs (brand protection signal) or different registrars (popular keyword signal). Use web_search to verify if they resolve to the same website. 3. Run trademark database checks across all four major databases. Primary method is Claude for Chrome — open each database, search for [prefix], and read results directly. If Claude for Chrome is not available, fall back to providing pre-filled links as described below. Present findings from each database inline as they come in — do not wait for all four before reporting. USPTO: - Chrome: navigate to https://search.uspto.gov/search?query=[prefix]&affiliate=web-sdmg-uspto.gov and read results directly. - Fallback (no Chrome): USPTO supports URL query parameters — provide this pre-filled link for the user to open: https://search.uspto.gov/search?query=[prefix]&affiliate=web-sdmg-uspto.gov - Extract: number of trademark hits, registrant names, goods/services classes, live vs dead status. EUIPO: - Chrome: navigate to https://euipo.europa.eu/eSearch/, locate the search input, type [prefix], submit, read results. - Fallback (no Chrome): EUIPO uses a JavaScript interface — URL parameters cannot pre-fill search. Provide the entry link and instruct the user: 'Please open https://euipo.europa.eu/eSearch/ and search for [prefix].' - Extract: EU trademark hits, registrant names, classes, status. WIPO: - Chrome: navigate to https://branddb.wipo.int/en/quicksearch, locate the search input, type [prefix], submit, read results. - Fallback (no Chrome): provide entry link and instruct: 'Please open https://branddb.wipo.int/en/quicksearch and search for [prefix].' - Extract: international trademark hits, registrant names, designating countries, status. TMview: - Chrome: navigate to https://www.tmdn.org/tmview/#/quicksearch, locate the search input, type [prefix], submit, read results. - Fallback (no Chrome): provide entry link and instruct: 'Please open https://www.tmdn.org/tmview/#/quicksearch and search for [prefix].' - Extract: aggregate hits across all participating offices, notable registrants. If a database is unreachable or returns an error, note it in the report and continue — do not halt the workflow. 4. Synthesize all findings into a report, framed according to the user's stated intent (risk-focused or opportunity-focused). The report must include: - Discovered entities: websites/companies using this keyword, their business, scale, founding year. - TLD distribution: cross-TLD registration pattern and registrar correlation. - Trademark database summary: hits per database, live marks found, relevant classes. If no hits found in a database, state that clearly — absence of results does not guarantee the mark is clear. - Risk assessment based on the three UDRP principles (confusing similarity, rights or legitimate interests, bad faith). For generic word combinations, note that risk is typically lower. Factor in registration age. Do NOT make legal conclusions. - Disclaimer: 'For reference only, does not constitute legal advice. Trademark searches are not exhaustive — consult a qualified IP attorney before making registration or investment decisions.' 5. After presenting the report, ask the user what they want to do next. Tailor follow-up based on their response: - Wants to proceed with registration → suggest available or bulk_available. - Wants deeper analysis → suggest analyze. - Wants alternatives → suggest plan_b or name_advisor. - Wants to find buyers → use web_search findings to identify potential buyers, suggest valuation_cma. - Wants monitoring → suggest set_monitor. Key principles: present facts, not legal judgments. Do NOT claim a trademark exists or does not exist based on partial results. Claude for Chrome reads all four databases directly — the user should never need to search manually when Chrome is available. When Chrome is unavailable, always provide actionable fallback links with clear search instructions. Always end with the legal disclaimer. Disclose affiliate links.. It is categorised as a Destructive tool in the DomainKits MCP Server, which means it can permanently delete or destroy data. Block by default and require explicit approval.

How do I enforce a policy on brand_match? +

Register the DomainKits MCP server in PolicyLayer and add a rule for brand_match: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches DomainKits. Nothing to install.

What risk level is brand_match? +

brand_match is a Destructive tool with critical risk. Critical-risk tools should be blocked by default and only enabled with explicit human approval.

Can I rate-limit brand_match? +

Yes. Add a rate_limit block to the brand_match rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.

How do I block brand_match completely? +

Set action: deny in the PolicyLayer policy for brand_match. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.

What MCP server provides brand_match? +

brand_match is provided by the DomainKits MCP server (https://api.domainkits.com/v1/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.

Enforce policy on every DomainKits tool call.

Deterministic rules across all 38 DomainKits tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.

Free to start. No card required.

4,600+ MCP servers and 31,000+ tools scanned and risk-classified.

// GET IN TOUCH

Have a question or want to learn more? Send us a message.

Message sent.

We'll get back to you soon.