MCP tools reference
This page and the three that follow are generated from the server's own tool list, so the parameters below are exactly the ones the running server accepts. If you are looking for worked examples rather than a parameter reference, start with Tool workflows.
The nine tools
| Tool | What it does | Approval |
|---|---|---|
search_operations |
Search OpusDNS API operations | No |
describe_operation |
Describe an OpusDNS API operation | No |
call_operation |
Call an OpusDNS API operation | Depends on the operation |
bulk_preview |
Preview a bulk domain operation | No |
bulk_submit |
Submit a bulk domain operation | Yes |
job_batch_status |
Get job batch status | No |
job_batch_control |
Control a job batch | Yes |
portfolio_summary |
Summarize the domain portfolio | No |
portfolio_query |
Query the domain portfolio | No |
Every tool rejects arguments it does not declare.
What the model is told
The server sends this text as its instructions when a client connects, so
it is what the model on the other end reads before it picks a tool. It is
reproduced verbatim.
OpusDNS Domain API. No code execution.
Single operation: search_operations -> describe_operation -> call_operation.
A single exact search match inlines "detail", so describe_operation can be skipped.
Multi-domain mutations: always bulk_preview -> bulk_submit, never call_operation in a
loop. You pass a selector (the GET /v1/domains filter set) and one shared template;
domains are resolved server-side, so never transcribe domain names yourself. Track
submitted batches with job_batch_status and steer them with job_batch_control.
Portfolio reads: portfolio_summary for totals, portfolio_query for field-projected rows.
Sub-organizations: every tool acts on the signed-in account unless you pass
organizationId, which must name a sub-organization of it. Ask the user which one before
guessing, and keep it on every call of a sequence -- preview and submit that disagree
about it are two different actions.
Operations that write, cost money, or destroy resources require explicit user approval
before they run. This is enforced server-side, not by these instructions. If a call comes
back with status "confirmation_required", ask the user, then retry the SAME call with
confirmationToken added and nothing else changed -- a different selector, body or
organizationId is a different action and will be refused. "declined" means stop.
Reading a result: status "ok" is a 2xx, status "api_error" is a 4xx or 5xx from the
OpusDNS API and is a normal result carrying httpStatus and the API's problem detail in
data -- report it, do not retry blindly. status "error" means the call did not reach the
API; its "code" says why: invalid_request or unknown_operation mean fix the arguments,
authentication_required means sign in, upstream_timeout and upstream_unavailable are
transient and may be retried once after a pause. truncated true means the response was
cut off: narrow the request instead of repeating it.
The tool list carries a freshness hint of 15 minutes (ttlMs: 900000), so a client
may cache it that long. The list is identical for every caller.

