Domain alternatives workflow. Call when a user's target domain is unavailable and they need alternative options across different lifecycle stages — for example after available or bulk_available returns unavailable, or as a follow-up from analyze or name_advisor when a candidate is taken. Do NOT c...
Risk signalsBulk/mass operation — affects multiple targets · Admin/system-level operation
Part of the DomainKits server.
Free to start. No card required.
AI agents use plan_b to create or modify resources in DomainKits. Write operations carry medium risk because an autonomous agent could trigger bulk unintended modifications. Rate limits prevent a single agent session from making hundreds of changes in rapid succession. Argument validation ensures the agent passes expected values.
Without a policy, an AI agent could call plan_b repeatedly, creating or modifying resources faster than any human could review. PolicyLayer's rate limiting ensures write operations happen at a controlled pace, and argument validation catches malformed or unexpected inputs before they reach DomainKits.
Write tools can modify data. A rate limit prevents runaway bulk operations from AI agents.
{
"version": "1",
"default": "deny",
"tools": {
"plan_b": {
"limits": [
{
"counter": "plan_b_rate",
"window": "minute",
"max": 30,
"scope": "grant"
}
]
}
}
}See the full DomainKits policy for all 38 tools.
These attack patterns abuse exactly the kind of access plan_b gives an agent. Each links to the full case and the policy that stops it:
Other write tools across the catalogue. The same approach applies to each: rate-limit and validate the arguments.
Domain alternatives workflow. Call when a user's target domain is unavailable and they need alternative options across different lifecycle stages — for example after available or bulk_available returns unavailable, or as a follow-up from analyze or name_advisor when a candidate is taken. Do NOT call when the user is starting from scratch without a target (use name_advisor), already knows their keyword and wants creative variations (use domain_generator), or wants to analyze the taken domain itself (use analyze). This is a multi-turn workflow. Stop and wait for user input at every checkpoint. Workflow: 1. Understand User Needs — extract core keywords from the unavailable domain (e.g., getflow.com → keyword: flow, pattern: prefix+root). Then ask the user: what appealed to you about this domain (the keyword, the length, the sound)? Are you open to other TLDs or .com only? Would you consider purchasing a registered domain, or only free registration / backorder? Do NOT search until the user responds — their motivation determines the entire search strategy. 2. Lifecycle Search — search by priority: deleted (free registration, highest priority) → expired (backorderable) → aged (registered, only if user is willing to purchase). For each tool, try the keyword in different positions (start, end) to maximize coverage — e.g., searching 'flow' at start and end will surface very different results. If a strong match is found in deleted, note it as a top recommendation. 3. Creative Variants — based on what the user liked about the original domain, generate 15-20 creative variants respecting their TLD preference (default .com). Avoid concatenations creating sensitive words or offensive abbreviations. Verify all with bulk_available. 4. Present Results — organize all findings layered by acquisition method from easiest to most involved: free registration (deleted + available variants) → backorderable (expired) → purchasable (aged for-sale) → monitorable (worth watching). Every domain must include the appropriate acquisition link. Ask the user which options interest them. 5. Follow-up — based on user choice: generate more variations, run brand_match, set up set_monitor, do deeper analysis with analyze or expired_analysis, or run valuation_cma. Key principles: - Default to .com only unless user specifies otherwise. - Every domain presented must include an acquisition link (register_url, backorder_url, or sale link). - Disclose affiliate links.. It is categorised as a Write tool in the DomainKits MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
Register the DomainKits MCP server in PolicyLayer and add a rule for plan_b: 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.
plan_b is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the plan_b 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.
Set action: deny in the PolicyLayer policy for plan_b. 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.
plan_b 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.
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.