Skip to main content
Glama
iracic82

infoblox-ddi-mcp

by iracic82

manage_dns_zone

Destructive

Manage DNS zones and related infrastructure: views, RPZ, delegations, ACLs, NSGs, servers, hosts, services. Perform lifecycle operations: create, list, get, update, delete, sign, copy, reorder.

Instructions

Manage DNS zones, views, RPZ, delegations, ACLs, NSGs, servers, hosts, services, and global config. USE THIS for zone lifecycle operations. For DNS record CRUD use manage_dns_record(). For record creation use provision_dns().

Quick routing guide:

  • Authoritative zones: resource_type="auth_zone" (default) → create, list, get, delete, sign, unsign, dnssec_status, copy

  • Forward zones: resource_type="forward_zone" → create, list, copy

  • DNS views: resource_type="dns_view" → create, list, get, update, delete

  • RPZ (Response Policy Zones): resource_type="rpz" → create, list, get, update, delete, reorder

  • Delegations: resource_type="delegation" → create, list, get, update, delete

  • DNS ACLs: resource_type="dns_acl" → create, list, get, update, delete

  • Auth NSGs: resource_type="auth_nsg" → create, list, get, update, delete

  • Forward NSGs: resource_type="forward_nsg" → create, list, get, update, delete

  • DNS Servers: resource_type="dns_server" → create, list, get, update, delete

  • DNS Hosts: resource_type="dns_host" → list, get, update

  • DNS Services: resource_type="dns_service" → list, get

  • DNS Global: resource_type="dns_global" → get, update

IMPORTANT: ALL mutating actions (create, update, delete) default to dry_run=True and must be explicitly set to dry_run=False to execute. sign/unsign/dnssec_status only work with auth_zone. reorder only works with rpz.

View scoping: when view is supplied on list/get/delete, it MUST be the exact DNS view name configured in Infoblox (not the literal string "default" unless the customer named a view that). Use manage_dns_zone(action="list", resource_type="dns_view") to see the actual view names first. UUIDs (dns/view/...) are also accepted.

Args: action: Operation to perform resource_type: DNS resource type to manage fqdn: Zone FQDN for create/delete (e.g., "example.com") name: Name for dns_view/acl/nsg/server create primary_type: For auth/rpz zones — "cloud" or "external" view: DNS view name (optional) target_view: Target view for copy action forward_to: List of forwarder IPs for forward zones delegation_servers: List of delegation server objects for delegation create zone_ids: List of zone IDs for sign/unsign/reorder operations disabled: Set zone disabled state (for update) comment: Description resource_id: Resource ID for get/update/delete/dnssec_status/copy tags: Resource tags dry_run: If True (default), delete shows record count only. Set False to execute.

Returns: Zone operation result

Examples: - manage_dns_zone(action="list") → all authoritative zones - manage_dns_zone(action="list", resource_type="dns_acl") → all DNS ACLs - manage_dns_zone(action="create", resource_type="dns_acl", name="internal-acl") - manage_dns_zone(action="create", resource_type="auth_nsg", name="primary-nsg") - manage_dns_zone(action="copy", resource_type="auth_zone", resource_id="dns/auth_zone/abc", target_view="external") - manage_dns_zone(action="get", resource_type="dns_global") - manage_dns_zone(action="list", resource_type="dns_service") → all DNS services - manage_dns_zone(action="sign", resource_type="auth_zone", zone_ids=["dns/auth_zone/abc"]) - manage_dns_zone(action="reorder", resource_type="rpz", zone_ids=["id1", "id2"]) - manage_dns_zone(action="delete", fqdn="old.example.com", dry_run=False)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fqdnNo
nameNo
tagsNo
viewNo
actionYes
commentNo
dry_runNo
disabledNo
zone_idsNo
forward_toNo
resource_idNo
target_viewNo
primary_typeNo
resource_typeNoauth_zone
delegation_serversNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

Adds critical behavioral context beyond the annotations: dry_run defaults to True for mutating actions, sign/unsign/dnssec_status restricted to auth_zone, reorder restricted to rpz, and the view scoping requirement with a recommendation to list view names first. No contradiction with the destructiveHint annotation; the dry_run safety is a valuable complement.

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?

The description is long but exceptionally well-structured: a purpose statement, routing guide, important notes, args, and examples. Every section provides high-value, non-redundant information. The front-loaded sibling differentiation and routing table make it easy to scan.

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 tool with 15 parameters and 12 resource types, the description is remarkably complete. It covers action/resource_type matrices, dry-run safety, view scoping nuances, and provides 11 examples. Since an output schema exists, the terse 'Returns: Zone operation result' is acceptable—return format is documented elsewhere.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the full burden—and it succeeds. The Args section explains all 15 parameters with contextual meanings (e.g., 'primary_type: For auth/rpz zones — cloud or external', 'zone_ids: List of zone IDs for sign/unsign/reorder operations'). Examples further demonstrate parameter usage for different resource types.

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?

The description clearly states the tool manages DNS zones and related resources, and explicitly distinguishes it from siblings: 'USE THIS for zone lifecycle operations. For DNS record CRUD use manage_dns_record(). For record creation use provision_dns().' The broad resource list is anchored by a specific directive.

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?

Provides an extensive quick routing guide mapping each resource_type to supported actions, explicitly names alternative tools, and gives operational caveats like dry_run behavior and view scoping. This goes far beyond minimal guidance and gives concrete when-to-use and when-not-to-use instructions.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/iracic82/infoblox-ddi-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server