Kleap

Buy Domain

buy_domain

Start buying a domain: returns a Stripe checkout_url (valid 30 min) that the USER must open and pay. Nothing is bought until they complete checkout — give them the link, never say it is purchased. With app_id it is connected to that app after payment.

Input Schema

TableJSON Schema

Name	Required	Description
`years`	No	1-10, default 1
`app_id`	No	App to connect it to
`domain`	Yes	e.g. 'mybakery.com'
`context`	Yes	Why this call, in one short sentence. Used to improve the connector; never include credentials or personal data.
`registrant`	No	The domain OWNER (legal registrant) — can differ from the person paying. Ask the user for it; if omitted, the payer's billing details are used.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`price`	No
`years`	No
`domain`	No
`currency`	No
`expires_at`	No
`checkout_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

addedInput schema / properties / registrant

Added value: +{
+  "additionalProperties": false,
+  "description": "The domain OWNER (legal registrant) — can differ from the person paying. Ask the user for it; if omitted, the payer's billing details are used.",
+  "properties": {
+    "address": {
+      "type": "string"
+    },
+    "address2": {
+      "type": "string"
+    },
+    "city": {
+      "type": "string"
+    },
+    "country": {
+      "description": "ISO 3166-1 alpha-2, e.g. FR",
+      "type": "string"
+    },
+    "email": {
+      "type": "string"
+    },
+    "first_name": {
+      "type": "string"
+    },
+    "last_name": {
+      "type": "string"
+    },
+    "organization": {
+      "type": "string"
+    },
+    "phone": {
+      "description": "International format, e.g. +33 6 12 34 56 78",
+      "type": "string"
+    },
+    "postal_code": {
+      "description": "Required except in countries without postal codes",
+      "type": "string"
+    },
+    "state": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "first_name",
+    "last_name",
+    "email",
+    "phone",
+    "address",
+    "city",
+    "country"
+  ],
+  "type": "object"
+}

AddedSep 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only declare a non-read-only, open-world, non-destructive mutation. The description adds genuinely new behavior: the call does not complete a purchase, the URL expires in 30 minutes, the user must act, and app_id causes post-payment connection. This is exactly the extra context annotations cannot carry.

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?

Three short sentences, front-loaded with the core action and the critical constraint that nothing is purchased yet. Every clause earns its place; 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?

Although an output schema exists, the description still explains the key returned value and its time limit, and covers the post-payment app linkage. For a payment-initiation tool this is complete enough for an agent to call and report correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning for app_id beyond the schema's terse 'App to connect it to' by specifying the connection happens after payment. Other params (years, domain, registrant, context) are left to the schema.

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 buying a domain') and immediately names the artifact produced (a Stripe checkout_url). It is clearly distinguishable from siblings like check_domain, search_domains, and connect_domain.

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 operational guidance: open the link and pay, nothing is bought until checkout completes, and the agent must never claim the domain is purchased. It does not explicitly name alternative tools such as search_domains for lookups, so it falls just short of full when/when-not routing.

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

All Kleap 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?