InfraNest

List domains

list_domains

Read-onlyIdempotent

Your domains, paginated with page and per_page (up to 200), each with its tags, advisor issue count and who hosts its website and mail. Filter with search, credential, tag, active, expiring_soon, autorenew_off, website, mail or archived (archived domains are left out unless asked for). Registration orders that failed are not domains you hold and are left out too; pass include_failed=1 to list them, and meta.counts.failed says how many there are. Sort with sort (domain, registrar, expires) and dir. advisor_issues is only a count: domain_findings says what the issues are, for every domain in one call.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_domains"
  }
}

Input Schema

Name	Required	Description
`tag`	No	Only things with this tag id.
`page`	No	Page number, from 1.
`sort`	No	Sort order.
`search`	No	Matches the domain name.
`per_page`	No	Rows per page, up to 200 (default 25).
`autorenew_off`	No	Only domains that will not renew by themselves.
`expiring_soon`	No	Only domains that expire soon.
`include_failed`	No	Also list registration orders that failed. They are not domains you hold, so they are left out unless asked for.
`organization_id`	No	The organization to read. Leave it out when the token reaches only one.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 30, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint, so the safety bar is covered; the description adds real behavioral context beyond them – default exclusions (archived, failed), a 200-row pagination ceiling, the meta.counts.failed signal, and the caveat that advisor_issues is a count only. Return-shape hints ('tags, advisor issue count and who hosts its website and mail') further help, though nothing is said about total counts or sort-stability.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and pagination lead, which is good, but the rest is a dense run-on that packs nine-plus filters into one sentence and partially restates schema text ('They are not domains you hold, so they are left out unless asked for' duplicates the include_failed description). It would read better as short grouped sentences: scope, defaults, filters, sorting, sibling routing.

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?

With no output schema and no annotations covering return values, the description still conveys what each row contains, how pagination works, what is excluded by default, and where to go for issue detail. An agent has enough to call it correctly and interpret the result without further probing.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already carries the per-parameter burden and a 3 baseline applies. The description does add semantic value (archived/failed default behavior, advisor_issues as a count), but it also names filters that do not exist in the schema – credential, active, website, mail, archived, dir – which forces the agent to reconcile the description against the schema rather than rely on it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource and its shape ('Your domains, paginated...'), and distinguishes itself from a sibling by routing issue detail to domain_findings. It never states the verb 'list' explicitly (the title does), but the intent is unambiguous and no sibling list_domains-adjacent tool competes for the same call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete selection guidance: archived domains are excluded unless requested, failed registration orders are excluded unless include_failed=1, and issue detail belongs to domain_findings rather than this tool. It stops short of a general 'use this when / not when' framing, but the conditional routing is explicit enough to guide a call.

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

All InfraNest tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.