Skip to main content
Glama

recommend_domain

Read-only

Get AI-recommended domain suggestions for a keyword or theme (e.g. "tom", "crypto", "defi"). Returns creative name + TLD combos with a category, each cross-checked for availability, priced, and given a register link. Use when a user asks "suggest names", "find me a domain about X", or "give me some .xrp ideas".

Input Schema

NameRequiredDescriptionDefault
tldsNoTLDs to include (without dots), e.g. ["xrp","xrpfi"]. Omit for all.
limitNoHow many suggestions to return.
queryYesKeyword or theme to base suggestions on, e.g. "tom" or "crypto".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and external-lookup behavior are covered. The description adds real value beyond them by disclosing that results are cross-checked for availability, priced, and given a register link, and the 'AI-recommended' framing implies non-deterministic output consistent with 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.

Conciseness4/5

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

Three tight sentences: purpose first, output shape second, usage triggers last. Every sentence earns its place, though the example list is slightly repetitive across the description.

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

Completeness4/5

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

With no output schema, the description correctly compensates by describing the returned structure (name+TLD, category, availability, price, register link). An agent has enough to call it correctly; only the exact result field names remain unspecified.

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 both tlds and limit are already documented in the schema; the description only echoes the query examples ('tom', 'crypto', 'defi') and alludes to TLD filtering ('.xrp ideas'). Baseline 3 is appropriate since the schema carries the parameter burden.

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 (recommend domains) plus the scope ('for a keyword or theme') and distinguishes itself from siblings like check_domains and register_domain by being a generative suggestion tool. The output composition (name + TLD combos with category) makes the deliverable unambiguous.

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 trigger phrasings ('suggest names', 'find me a domain about X', '.xrp ideas') that map intent to tool selection. It does not explicitly contrast with the closest sibling (check_domains) or state when not to use it, so it stops short of a 5.

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.