Skip to main content
Glama

Doti Protocol (.i) MCP Server

register_domain

Register a permanent .i sovereign domain or generate on-chain transaction payload for contract execution across the 4 networks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNameYesThe .i domain name to register (e.g. "mybot.i")
targetChainIdNoNetwork where deposit is made: 42161 (Arbitrum), 10 (Optimism), 1 (Ethereum), 4663 (Robinhood). Defaults to 42161.
recipientAddressYesThe 0x EVM wallet address that will own the domain

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations, the description does disclose meaningful behavioral traits: registration is 'permanent', and the tool can 'generate on-chain transaction payload' rather than necessarily executing a transaction. However, it does not explain side effects, whether funds move, when payload generation happens, or what the caller receives.

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 description is a single sentence with minimal filler, but the 'or' clause makes it read as two competing responsibilities without clear separation. 'Sovereign' adds little functional value, and the sentence structure obscures rather than clarifies the tool's operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description leaves too much unexplained: when payload generation happens, what the payload contains, how targetChainId interacts with 'the 4 networks', and whether prior availability checks or deposits are needed. An agent cannot confidently determine the full call flow.

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 description coverage is 100%, so the schema already documents all three parameters. The description loosely connects to domainName and targetChainId ('the 4 networks') but adds no meaning beyond the schema. Baseline 3 is appropriate.

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 opens with a specific verb and resource: 'Register a permanent .i sovereign domain', which clearly identifies the primary action and object. The trailing clause 'or generate on-chain transaction payload for contract execution' introduces ambiguity about whether there are two modes, but the main purpose is still obvious.

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

Usage Guidelines2/5

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

No guidance is given about when to use this tool instead of related siblings like estimate_registration, check_domain_availability, or marketplace_buy_domain. The mention of 'the 4 networks' gives some context, but there are no exclusions, prerequisites, or alternative routing.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.