Exepal

Name Check (is a business name free?)

name_check

Read-onlyIdempotent

Business and startup name availability: .com .io .ai .co .app .dev domains, GitHub, npm, Bluesky and YouTube handles, links for X and LinkedIn, US trademark (USPTO) and WIPO search links, and a verdict. Use when a founder asks whether a business, startup, product or app name is available, or before registering a domain or handles. Pass name (e.g. Acme Labs; spaces are removed for domains). Returns verdict (strong, workable, risky), verdictText, score 0-100, domains[] {domain, status free/taken/unknown, registeredAt, registrar, buyUrl}, handles[] {platform, handle, status, url, how checked/manual}, trademark {usptoUrl, wipoUrl, note} and nextSteps[]. Domains use RDAP plus DNS; registry premium names can show as free. For Instagram, TikTok and a Google check for businesses already using the name, use name_check_report; for new name ideas, name_check_ideas. Price: $0.02 per call from Exepal credit; not charged if the call fails. Larger or cheaper variants, listed when the server URL ends in ?tools=all: name_check_report (adds Instagram, TikTok, more domains and a Google check for businesses using the name, $0.25); name_check_ideas (10 checked startup names for an idea, $0.50).

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": {
      "name": "<name>"
    },
    "name": "name_check"
  }
}

Input Schema

Name	Required	Description	Default
`name`	Yes	The business, startup or product name to check, e.g. Acme Labs (2-40 characters)

Output Schema

Name	Required	Description
`kind`	No	name-check
`name`	No
`slug`	No	The name as used for domains and handles
`level`	No	quick or report
`score`	No	0-100, higher is better
`google`	No	Report level only
`domains`	No
`handles`	No
`verdict`	No	strong, workable or risky
`checkedAt`	No	ISO 8601
`nextSteps`	No
`trademark`	No
`verdictText`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already carry readOnly/openWorld/idempotent/non-destructive, and the description adds real operational context beyond them: data sources (RDAP plus DNS), a genuine caveat that registry premium names can show as free, cost ($0.02 per call from Exepal credit), and the fact that failed calls are not charged. That is exactly the kind of caveat-and-cost disclosure an agent needs before spending money.

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?

Front-loaded and dense, with purpose first, return shape second, alternatives and pricing last. It loses a point for redundancy: the routing to name_check_report for Instagram/TikTok/Google is stated twice — once as guidance and again in the variant/pricing list — and the return-shape enumeration partially duplicates the output schema.

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?

Covers input format, data sources, limitations, alternatives, and cost, which is more than enough for a one-parameter read-only check. Since an output schema exists, the long field-by-field listing of verdict/domains/handles/trademark is partly wasted text, but the surrounding behavioral caveats justify the length.

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?

With 100% schema coverage on a single required parameter, the baseline is 3; the description earns an extra point for disclosing normalization behavior ("spaces are removed for domains") which the schema does not state and which affects how the agent should format the name.

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?

Opens with a specific verb+resource ("Business and startup name availability") and enumerates exactly what is checked: .com/.io/.ai/.co/.app/.dev domains, GitHub, npm, Bluesky and YouTube handles, X/LinkedIn links, USPTO and WIPO. It explicitly names the two more expensive siblings so the agent can distinguish this tool from them at a glance.

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

Usage Guidelines5/5

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

Gives explicit when-to-use ("when a founder asks whether a business, startup, product or app name is available, or before registering a domain or handles") and explicit routing rules: use name_check_report for Instagram/TikTok/Google-existing-business checks and name_check_ideas for generating new names. The exclusions are named, not inferred.

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

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