Xpress Flow Systems

create_domain_order

Start an order to register an available domain for a person. This does not charge anyone. It returns an approval_url that the person must open and pay (in US dollars outside Nigeria, in naira in Nigeria); the name is held for 60 minutes. Send approval_url to your user and wait. Poll get_order_status afterwards.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "domain": "<domain>",
      "customer_name": "<customer_name>",
      "customer_email": "<customer_email>",
      "customer_phone": "<customer_phone>",
      "address": "<address>",
      "city": "<city>",
      "state": "<state>",
      "country": "<country>",
      "accept_terms": "<accept_terms>"
    },
    "name": "create_domain_order"
  }
}

Input Schema

Name	Required	Description
`city`	Yes	City.
`state`	Yes	State or region.
`domain`	Yes	The available domain to register.
`address`	Yes	Street address of the registrant.
`country`	Yes	Country, for example Nigeria.
`currency`	No	Optional: USD or NGN, the currency the person pays in. By default US dollars outside Nigeria and naira in Nigeria, from where the request comes from.
`accept_terms`	Yes	Set true only if your user has agreed to the Terms of Use and Privacy Policy on this website.
`organisation`	No	Optional organisation name.
`customer_name`	Yes	Full name of the person who will own the domain.
`customer_email`	Yes	Their email address.
`customer_phone`	Yes	A phone number we can reach, for example 08012345678.
`email_verification_token`	No	verification_token from verify_email_code for this email (required while email checks are on).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

addedInput schema / properties / email_verification_token

Added value: +{
+  "description": "verification_token from verify_email_code for this email (required while email checks are on).",
+  "type": "string"
+}

First observedOct 22, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: no charge is made, an approval_url is returned, currency depends on the requester's location (USD outside Nigeria, NGN inside), and the name is held for only 60 minutes. This is exactly the human-in-the-loop and time-bound behavior an agent needs, consistent with readOnlyHint=false and idempotentHint=false.

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

Conciseness5/5

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

Four short sentences, front-loaded with the verb and resource, then payment model, then the required next action. Every sentence contributes distinct, actionable information with no filler.

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?

No output schema exists, yet the description explains the key return value (approval_url), the hold duration, and the follow-up tool (get_order_status) an agent must poll. Nothing essential to correct invocation is missing.

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 all 12 parameters are already documented in the schema, including the currency default and the conditional email_verification_token. The description adds little parameter-level meaning beyond reinforcing the currency behavior, so baseline 3 applies.

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

Purpose5/5

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

States a specific verb+resource ('Start an order to register an available domain for a person') and scopes it precisely against the esim/proxy order siblings. The word 'available' signals that availability must be established, implicitly distinguishing it from check_domain_availability.

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?

Gives explicit workflow guidance: send approval_url to the user and wait, then poll get_order_status afterwards. It does not explicitly name check_domain_availability as a prerequisite or state exclusions (e.g. transfers/renewals), so it stops short of full when/when-not coverage.

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

All Xpress Flow Systems 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.

Resources

Need Help?