Get the DNS records a mail domain needs (MX, SPF, DKIM, ...) — for customers managing DNS externally. Requires authentication. Required: domain.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | ||
| sessionKey | No | Session key (osk_...) returned by checkDeviceLoginStatus. Pass it on every call when logged in via the in-chat device flow; omit when connected via OAuth. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses authentication requirements and scopes the tool to external DNS management. It does not clarify whether the tool returns recommended records vs. live DNS lookups, how invalid/unconfigured domains are handled, or the response shape, which would be valuable with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action and resource. The only minor inefficiency is that 'Required: domain' restates schema information, but the overall length is appropriate and free of unnecessary prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description adequately covers the purpose, the target user scenario, authentication, and representative record types (MX, SPF, DKIM). It stops short of full completeness because it does not define the output structure or explicitly distinguish itself from mail DNS verification and generic DNS record tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the undocumented 'domain' parameter is not explained beyond repeating that it is 'Required'—which the schema already states. The description does not explain domain format or constraints, and it says nothing about sessionKey beyond what the schema already provides. It fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action ('Get') and a precise resource: 'the DNS records a mail domain needs (MX, SPF, DKIM, ...)'. This clearly distinguishes it from generic DNS sibling tools like listDnsRecords or getDnsRecord by framing it around mail-domain requirements for externally managed DNS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives useful context with 'for customers managing DNS externally' and notes authentication, so an agent can infer the intended scenario. However, it does not explicitly name alternatives like listDnsRecords or verifyMailDns, nor does it state when not to use this tool. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
The set has several near-duplicate or heavily overlapping tools: initiateTransfer and transferDomain appear to do the same thing, and generateDomainSuggestions, bulkDomainSuggestions, suggestAlternatives, spinDomainWords, and addPrefix/addSuffixToDomain all occupy suggestion space. Account/profile tools like getAccountSummary, getMyProfile, getRecentActivity, and getMyAuditLogs also blur together.
Many tools follow verb_noun camelCase (createDnsRecord, listInvoices, updateContact), but the broader set mixes styles: osirAppCreateUpload vs osirAppList vs osirAppStatus, plus inconsistent verbs like check/verify/validate/preview for similar lookup actions. The naming is readable but not predictable across the full surface.
105 tools is an extreme count for any single MCP server, even one spanning domain registration, DNS, VPS, email, billing, app deployment, and site publishing. The surface would be far more coherent split into focused servers by domain.
Core domain, DNS, billing, VPS, mail, and app deployment workflows are broadly covered. However, there are notable gaps: no way to update or reassign the contacts on an existing domain, no update operation for host/glue records, and no VPS power operations like reboot or stop outside the external control panel.