list_domainsList domains available to the current registered account, including miniurl.com and active custom domains.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| data | No | ||
| meta | No | ||
| error | No | ||
| success | Yes | ||
| approval | No | ||
| retryable | No | ||
| request_id | Yes | ||
| retry_after | No | ||
| next_actions | No | ||
| required_scope | No | ||
| user_action_required | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds value by specifying that only domains for the current account are listed, and that both miniurl.com and active custom domains are included. This hints at behavioral filtering (inactive domains excluded) not covered by annotations.
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 a single, front-loaded sentence that immediately states the action and subject. It contains no fluff or redundant phrasing. Every word contributes to understanding.
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, parameterless listing tool, the description is sufficiently complete. It tells the user what will be listed and the scope, while the presence of an output schema handles return value details. No further information about pagination or errors is necessary for this level of complexity.
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?
The tool has zero parameters, so the baseline is 4 per rubric. The schema coverage is naturally 100% and there is no parameter information to add. The description correctly avoids fabricating parameter details.
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?
The description clearly states the action (list), the resource (domains), and the scope (current registered account). It also distinguishes itself from siblings like add_domain, delete_domain, and verify_domain by focusing on read-only enumeration. The mention of including miniurl.com and active custom domains adds specificity without ambiguity.
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?
The description implies when to use this tool: to view available domains for the current account. It does not explicitly state exclusions or alternative tools, but the context is clear enough for a simple listing operation. Since it is a read-only list, no complex usage guidance is needed.
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.
Each tool targets a clearly distinct resource and action: links, domains, tags, auth, and account status are all separate concerns. Even similar tools like shorten_url and bulk_create_links are differentiated by single vs. batch creation, and check_alias is distinct from get_link by checking availability before creation.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., add_domain, delete_link, list_tags, verify_registration_code). Mixed verb styles like tag/untag and shorten_url are still predictable and fit the established convention.
At 23 tools, the set is on the heavy side and falls in the 16-25 borderline range. The number is somewhat justified by the broad scope (links, domains, tags, auth, analytics), but it approaches the upper limit where an agent may have difficulty selecting between many options.
The tool surface covers the full lifecycle of short links (create, read, update, delete, list, stats), domain management (add, delete, verify, list), tags (create, list, delete, tag/untag), and account/auth flows (guest tokens, registration, pro upgrade). It is hard to identify any critical missing operation for the stated purpose.