Monitor taken usernames and get alerted when they drop, plus handle, domain, and trademark checks.
Scored across 11 tools
Most tools are clearly distinct: generate vs alternatives, check vs sub-checks, watch/unwatch/watches. The only slight overlap is between namesniper_check and the separate namesniper_check_domains/namesniper_check_social, but descriptions explicitly direct users to the more specific tools when only one dimension is needed.
All tools follow a consistent 'namesniper_verb_noun' pattern with clear verbs (generate, check, check_domains, check_social, watch, unwatch, watches). The naming is predictable and makes it easy for an agent to infer tool purposes from names alone.
11 tools is well within the optimal 3-15 range for a brand-name validation and generation server. Each tool serves a distinct function (generation, alternatives, domain checks, social checks, trademark screening, Roblox rarity, Telegram price, watch management), and none feel redundant.
The tool surface covers the full brand-name lifecycle: generation (generate, alternatives), availability checking (check, check_domains, check_social), trademark screening, niche checks (Roblox, Telegram), and watch management (watch, unwatch, watches). There are no obvious gaps for the stated purpose of brand name evaluation and acquisition.
Generate variations of an existing brand name using deterministic prefix, suffix, compound, and wordplay patterns. Returns JSON alternatives[] each with the name, the pattern used, a description, and a 0-100 brandability score. Use this to riff on a name the user already has; use namesniper_generate for brand-new AI ideas from a description. Free, no API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The base brand name | |
| count | No | Number of alternatives to generate (1-20, default: 8) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the deterministic generation method, the exact output structure (JSON with name, pattern, description, brandability score), and that it's free with no API key. Missing details like rate limits or constraints on input length, but the core behavioral traits are well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences that front-load the purpose and output format, then nestle usage guidance and cost info. Every sentence earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple generation tool with two parameters and no output schema, the description adequately explains the return format, when to use vs alternatives, and cost/auth. It covers all necessary context without being verbose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because both parameters (name, count) have descriptions in the schema. The description does not add further semantics about parameters beyond what is already in the schema, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates variations of an existing brand name using specific deterministic patterns. It distinguishes from the sibling tool namesniper_generate by specifying that this tool works from an existing name, not from a description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to riff on a name the user already has; use namesniper_generate for brand-new AI ideas from a description.' This provides clear when-to-use guidance and names a specific alternative. Also notes 'Free, no API key needed,' which helps in deciding usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All-in-one brand name check: domain availability across TLDs, username availability across the major social platforms, an optional 0-100 brand score, and USPTO trademark screening. Returns JSON with per-TLD and per-platform results (each with an availability verdict and 0-1 confidence), availability summaries, brandScore, and trademark risk. Use namesniper_check_domains or namesniper_check_social instead when only one dimension is needed. Free without an API key (rate-limited; trademark is skipped and Instagram/TikTok/X return best-effort HTTP confidence); a paid key unlocks verified accuracy on those platforms plus trademark screening.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The brand name to check | |
| plan | No | Ignored - derived from your API key | |
| userId | No | Ignored - derived from your API key | |
| domains | No | TLDs to check (default: com,org,net,app,dev,tech,io,co,ai) | |
| platforms | No | Social platforms to check (default: the standard platform grid; excludes Telegram, pass platforms explicitly including telegram to check it) | |
| trademark | No | Include trademark screening via USPTO — requires an API key and counts against the plan's monthly screening allowance; ignored for unauthenticated callers (default: true when authenticated) | |
| brandScore | No | Include brand score analysis (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: return format (JSON structure with per-TLD/per-platform results, availability verdicts, confidence scores, summaries, brandScore, trademark risk), limitations (free: rate-limited, trademark skipped, Instagram/TikTok/X return best-effort HTTP confidence), and authentication effects (paid key unlocks verified accuracy).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-organized paragraph that front-loads the core purpose, then lists components, return format, usage alternatives, and cost/limitation details. Every sentence adds value; there is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is remarkably complete. It explains the full output structure, behavioral differences across authentication states, and when to use sibling tools. Nothing essential is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the description adds meaningful context beyond the schema: it explains that 'plan' and 'userId' are ignored and derived from the API key, provides default TLDs and platforms, and clarifies the behavior of 'trademark' and 'brandScore' based on authentication. This enriches the agent's understanding of parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs an 'all-in-one brand name check' covering domains, social usernames, brand score, and trademark. It explicitly distinguishes from siblings by naming 'namesniper_check_domains' and 'namesniper_check_social' as alternatives for single-dimension checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use this tool vs. alternatives ('use namesniper_check_domains or namesniper_check_social instead when only one dimension is needed'). It also explains the behavior based on authentication (free vs. paid key), including rate limits and feature availability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check whether a domain name is registered across multiple TLDs using DNS lookups with a registry-data fallback. Returns JSON with per-TLD results (available true/false with a 0-1 confidence score) and an available/taken summary. Pass details=true to add a registration record on each taken TLD (registrar, registeredAt, expiresAt, status, dropStage) read from the registry; registrant identity is usually redacted. Faster and narrower than namesniper_check when social handles are not needed. Free, rate-limited.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The domain name to check (without TLD) | |
| tlds | No | TLDs to check (default: com,org,net,app,dev,tech,io,co,ai) | |
| details | No | Attach registry registration details (registrar, dates, status, drop stage) to taken TLDs (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the tool is free, rate-limited, uses DNS with a fallback, details parameter effect (details=true adds registration record), and notes registrant identity is usually redacted. It doesn't specify exact rate limits or what happens on DNS failure, but covers key behavioral traits well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and front-loaded with the core purpose, then adds optional detail, comparison to sibling, and constraints. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 params (100% schema coverage) and no output schema. The description clearly explains the input parameters and the JSON structure of the output (per-TLD results with available/confidence and summary). It doesn't describe the exact JSON keys for the summary, and with no output schema, a bit more detail on the return format could help, but it's mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all 3 parameters. The description adds value by explaining the 'details' parameter adds registration record (registrar, dates, status, dropStage) and clarifies registrant identity is redacted, but for 'name' and 'tlds' it adds little 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks domain registration across multiple TLDs using DNS with a fallback, specifying the verb 'check', the resource 'domain names', the mechanism 'DNS lookups with registry-data fallback', and differentiates from sibling namesniper_check by noting it's faster and narrower when social handles are not needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: when social handles are not needed, as it's 'Faster and narrower than namesniper_check'. It also states it's free but rate-limited, providing clear guidance on usage context and an alternative (namesniper_check) for broader checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check username availability across the major social platforms concurrently. Returns JSON with per-platform results (status available/taken/error with a 0-1 confidence score) and an available/taken summary. Narrower than namesniper_check when domains are not needed; if a wanted handle is taken, offer namesniper_watch. Free and rate-limited without an API key (Instagram, TikTok, and X/Twitter return best-effort HTTP confidence); a paid key unlocks verified accuracy on those three.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The username to check | |
| plan | No | Ignored - derived from your API key | |
| userId | No | Ignored - derived from your API key | |
| platforms | No | Platforms to check (default: the standard platform grid; excludes Telegram, pass platforms explicitly including telegram to check it) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses rate-limiting, the best-effort nature of Instagram/TikTok/X results without a paid key, and the concurrent check behavior. It does not explicitly state the tool is read-only or non-destructive, but the overall safety profile is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, dense paragraph that front-loads the core action and return format, then efficiently adds usage context and behavioral notes. Every sentence adds value with no redundant or vague statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema and annotations, the description provides a good mental model: it explains the return format, rate limits, API key tiers, and sibling relationships. It could improve by listing the exact default platforms or clarifying error handling, but overall it is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds context about the platforms parameter (default grid and Telegram exception) and that plan/userId are ignored. However, it does not significantly expand on the name parameter beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Check username availability across the major social platforms concurrently.' It clearly distinguishes itself from sibling tools by noting it is 'Narrower than namesniper_check when domains are not needed' and explains the JSON return format with per-platform status and confidence scores.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'if a wanted handle is taken, offer namesniper_watch' and contrasts with namesniper_check when domains are needed. It also explains the free vs. paid key context. However, it does not fully enumerate when not to use this tool (e.g., when domains or trademark checks are needed) beyond implying namesniper_check covers domains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate new brand name ideas with AI from a business or project description, each enriched with a live .com availability check. Non-deterministic: repeated calls produce different names (identical requests are served from a 24-hour cache and flagged with cached: true). Typical latency 5-30 seconds. Returns JSON names[] with the name, an explanation, tags, a confidence score, and comAvailable. Requires an API key (paid plan) and counts against a daily generation quota. To riff on a name the user already has, use namesniper_alternatives instead (free, deterministic).
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Number of names to generate (default: 25, max 30) | |
| style | No | Style: modern, classic, tech, creative, professional, playful, abstract, luxury, minimalist | |
| userId | No | Ignored - derived from your API key | |
| description | Yes | Business or project description to generate names for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does an excellent job: it discloses non-deterministic behavior, 24-hour caching with cached:true flag, typical latency 5-30 seconds, the return format (JSON names[] with fields), API key requirement, paid plan, and daily quota. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured: purpose first, then key behavioral traits, then alternatives. Every sentence adds unique value (caching, latency, quota, return shape, sibling guidance). Could be slightly tighter, but overall effective and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (generative AI, caching, latency, quota, no output schema), the description covers all essential aspects: what it does, non-determinism, caching behavior, performance expectations, return structure, authentication/quota, and alternatives. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameters. The description adds value beyond schema by clarifying that userId is ignored (derived from API key), and provides context for count (default 25, max 30) and style (enum listing). This enhances usability without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates new brand name ideas from a business description with live .com availability checks. It uses a specific verb ('Generate') and resource ('brand name ideas'), and later distinguishes from sibling namesniper_alternatives, leaving no ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'To riff on a name the user already has, use namesniper_alternatives instead (free, deterministic).' This directly tells the agent when not to use this tool and what alternative to use, fulfilling the usage guidelines dimension thoroughly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rate the rarity of a Roblox username (Common to Legendary, 0-100 score) from measured namespace saturation data and name structure, with a live availability check. Free, no API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | The Roblox username to rate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It adds useful context: the rating is based on measured namespace saturation and name structure, includes a live availability check, and is free with no API key needed. This gives an agent a good sense of how the tool behaves and its side effects (read-only, no auth required).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every clause adds value. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose, methodology, and key features (score, rarity category, live availability, free/no key). While there is no output schema, the description covers the expected return type (score and rarity category), making it reasonably complete for a single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'username' parameter. The description does not add extra parameter-level details beyond what the schema already states, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Rate') and resource ('Roblox username'), and clearly states the output (Common to Legendary, 0-100 score). It distinguishes itself from sibling tools by focusing on rarity rating rather than checking, generating, or watching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to rate a Roblox username's rarity. It provides context about how the rating is computed (namespace saturation and name structure) but does not explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up the recorded market price history of a Telegram username: peak and latest on-chain sale (in TON), live auction state, and bid activity, from public TON blockchain records. Free, no API key needed.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | The Telegram username to look up (without @) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that data comes from public TON blockchain records, states no API key is needed, and enumerates the return content (peak/latest sale, auction state, bid activity). However, it does not mention rate limits, error behavior, or explicitly confirm it is a read-only operation. With no annotations, this is adequate but modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the verb and resource, then lists key details; the second sentence adds access information. Every phrase contributes value and the structure is scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter lookup tool with no output schema, the description covers the core purpose, data source, and cost/authentication aspects. It does not describe return format or edge cases, but given the tool's simplicity, it is reasonably complete and informative enough for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter (username), including the clarification 'without @'. The description adds no additional parameter semantics, so it aligns with the baseline expected when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: looking up recorded market price history for a Telegram username, with specific data points (peak/latest sale, auction state, bid activity). It distinguishes itself from sibling tools like namesniper_check (availability) or namesniper_watch (tracking) by focusing on price history and on-chain auction data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for price history lookups and mentions it is free and requires no API key, which is a useful prerequisite. However, it does not explicitly state when to prefer this over sibling tools or provide any exclusions or alternative guidance. The context is clear but not formally differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a brand name for US trademark conflicts against the USPTO database with similarity analysis. Returns JSON with matching marks and a summary including an overall risk rating; with includeVariations, common spelling variations are screened too (slower, more lookups). A screening aid, not legal advice. Requires an API key (paid plan); each distinct name counts against the plan's monthly screening allowance (re-screening a name is free).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The brand name to screen | |
| userId | No | Ignored - derived from your API key | |
| includeVariations | No | Check common variations (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It details return format (JSON with matching marks and risk rating), behavior of includeVariations (slower, more lookups), authentication (API key required, paid plan), and cost model (screening allowance, re-screening free). This is a strong disclosure of behavioral traits, though it omits potential error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. The first sentence presents the core purpose and data source. The second explains the output and variation option. The third covers legal disclaimer and cost. Information is front-loaded and every sentence adds value. Ideal conciseness for a tool with three parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return value (JSON with matching marks and risk rating). It covers authentication, cost, and a behavioral variant (includeVariations). However, it does not explain error cases (e.g., invalid name, quota exceeded) or what 'matching marks' entails. For a moderately complex tool, this is mostly complete but could be slightly richer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explaining that includeVariations triggers 'common spelling variations' and notes it is 'slower, more lookups,' which is not in the schema description. This nuance helps agents weigh performance tradeoffs. The other parameters are well-documented in the schema, and the description's extra context on includeVariations justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'screen' and the resource 'brand name for US trademark conflicts against the USPTO database with similarity analysis.' It distinguishes from sibling tools by highlighting similarity analysis and the USPTO focus, which other tools like namesniper_check likely lack. The scope (US trademarks) and output (risk rating) are explicit, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the tool is for screening brand names and includes a disclaimer ('not legal advice') and cost implications (API key, allowance). However, it does not directly compare to sibling tools like namesniper_check or namesniper_alternatives, nor does it specify when to prefer this tool over others. The usage context is implied but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop monitoring a watched handle and free its slot. Pass the watch id from namesniper_watches, or a username (optionally narrowed to one platform) to remove all its watches. Returns JSON with the removed count and ids. Requires an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Watch id from namesniper_watches | |
| userId | No | Ignored - derived from your API key | |
| platform | No | Limit username-based removal to one platform | |
| username | No | Remove watches for this username across all platforms unless platform is given |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the action frees a slot and requires an API key, which are important behavioral traits. Since no annotations are provided, the description bears the full burden; this is adequate but could be more explicit about side effects (e.g., if removing a watch cannot be undone) or any rate limits. The description does not contradict any annotations (none exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first states the primary purpose, the second explains usage modes, and the third describes output and requirements. This is concise and front-loaded, with no wasted sentences. Could be slightly more succinct by merging the second and third sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and no annotations, the description adequately covers purpose, usage modes, required auth, and return format. The tool has 4 parameters but none required, and the complexity is moderate. The description provides enough information for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds context about the relationship between parameters (e.g., 'optionally narrowed to one platform') and notes that 'userId' is ignored, which adds value beyond the schema. However, the description does not explain all parameters in detail, and since no output schema is provided, the description's mention of return format ('returns JSON with the removed count and ids') helps fill that gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('stop monitoring a watched handle and free its slot') and the resource ('watched handle'), which distinguishes it from sibling tools like namesniper_watch (which adds watches) and namesniper_watches (which lists them). However, it does not explicitly contrast with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use the tool by mentioning the two modes (by watch id from namesniper_watches, or by username/username+platform) and explains how to use each. It does not explicitly mention when NOT to use it or offer alternatives beyond the sibling tools list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start monitoring a taken username so the user can claim it when it frees up or drops (alerts follow the plan's check schedule after two confirming checks). Creates one watch per platform against the plan's slot limit (already-watched pairs are skipped); checks then run automatically on a plan-based schedule and alerts are delivered in-app, by email, and to any configured webhooks. Returns JSON with created watch ids and the skipped count. List watches with namesniper_watches; stop one with namesniper_unwatch. Requires a paid API key (Pro or Business).
| Name | Required | Description | Default |
|---|---|---|---|
| userId | No | Ignored - derived from your API key | |
| username | Yes | The username/handle to watch | |
| platforms | No | Platforms to watch - required; each consumes one watch slot |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries transparency. It discloses slot limits, skip behavior for already-watched pairs, scheduling after two confirming checks, and delivery methods (in-app, email, webhooks). Return format is described briefly. This is thorough for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with no waste. Core purpose first, then behavioral details, then return format and sibling references. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description covers purpose, behavior, return, prerequisites, and related tools. It could mention error states like plan limit exceeded, but overall it is sufficiently complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about watch slots and skipping, but does not significantly augment parameter semantics beyond what the schema already provides (e.g., userId is ignored, platforms consume slots).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Start monitoring') and resource ('a taken username') and clearly distinguishes from siblings by naming namesniper_watches and namesniper_unwatch for listing and stopping watches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use (monitoring a taken username to claim it), mentions prerequisites (paid API key), and references sibling tools for related actions. It does not explicitly state when NOT to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List every handle the account is monitoring. Returns JSON watches[] with id, username, platform, watch status, last observed availability, last-checked and last-changed timestamps, and check count, plus slot usage {used, limit}. Use a watch id with namesniper_unwatch to stop monitoring it. Requires an API key.
| Name | Required | Description | Default |
|---|---|---|---|
| userId | No | Ignored - derived from your API key |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the return format (JSON array with specific fields, slot usage) and the authentication requirement (API key). This is sufficient for an agent to understand the tool's output and prerequisites. It could be slightly improved by explicitly stating that the operation is read-only and idempotent, but the current detail is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no wasted words. It front-loads the core purpose, then adds return structure and usage guidance. Every sentence earns its place, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description compensates by detailing the return fields (id, username, platform, watch status, etc.) and slot usage. It also ties to a sibling tool. However, it omits potential issues like pagination if the list is long, error handling, or rate limits. For a simple list tool, the description is mostly complete but has minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter (userId with description 'Ignored - derived from your API key'), so the baseline is 3. The tool description does not add any additional information about the parameter beyond what the schema already provides. No deduction is necessary, but no bonus either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'List every handle the account is monitoring.' This clearly distinguishes it from sibling tools like namesniper_watch (which adds a watch), namesniper_unwatch (which removes a watch), and namesniper_check (which checks availability). The purpose is unambiguous and well-scoped.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the primary use case (listing monitored handles) and explicitly recommends using the returned watch id with namesniper_unwatch to stop monitoring, providing a clear usage path. However, it does not offer explicit guidance on when not to use this tool—e.g., when to prefer namesniper_check for immediate availability checks or namesniper_alternatives for suggestions. The context is clear but excludes alternative use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
namesniper_alternatives4 fields changedInput schema / properties / count / descriptionPrevious value: -"Number of alternatives to generate (default: 8)"New value: +"Number of alternatives to generate (1-20, default: 8)"Input schema / properties / count / maximumAdded value: +20Input schema / properties / count / minimumAdded value: +1Input schema / properties / count / typePrevious value: -"number"New value: +"integer"namesniper_check2 fields changedInput schema / properties / planAdded value: +{
+ "description": "Ignored - derived from your API key",
+ "type": "string"
+}Input schema / properties / userId / descriptionPrevious value: -"Ignored — derived from your API key"New value: +"Ignored - derived from your API key"namesniper_check_domains1 field changedInput schema / properties / detailsAdded value: +{
+ "description": "Attach registry registration details (registrar, dates, status, drop stage) to taken TLDs (default: false)",
+ "type": "boolean"
+}namesniper_check_social2 fields changedInput schema / properties / planAdded value: +{
+ "description": "Ignored - derived from your API key",
+ "type": "string"
+}Input schema / properties / userIdAdded value: +{
+ "description": "Ignored - derived from your API key",
+ "type": "string"
+}namesniper_generate1 field changedInput schema / properties / userId / descriptionPrevious value: -"Ignored — derived from your API key"New value: +"Ignored - derived from your API key"namesniper_trademark1 field changedInput schema / properties / userId / descriptionPrevious value: -"Ignored — derived from your API key"New value: +"Ignored - derived from your API key"namesniper_unwatch1 field changedInput schema / properties / userId / descriptionPrevious value: -"Ignored — derived from your API key"New value: +"Ignored - derived from your API key"namesniper_watch1 field changedInput schema / properties / userId / descriptionPrevious value: -"Ignored — derived from your API key"New value: +"Ignored - derived from your API key"namesniper_watches1 field changedInput schema / properties / userId / descriptionPrevious value: -"Ignored — derived from your API key"New value: +"Ignored - derived from your API key"namesniper_check2 fields changedInput schema / properties / trademark / descriptionPrevious value: -"Include trademark screening via USPTO — requires an API key; ignored for unauthenticated callers (default: true when authenticated)"New value: +"Include trademark screening via USPTO — requires an API key and counts against the plan's monthly screening allowance; ignored for unauthenticated callers (default: true when authenticated)"Input schema / properties / userIdAdded value: +{
+ "description": "Ignored — derived from your API key",
+ "type": "string"
+}namesniper_generate2 fields changedInput schema / properties / count / descriptionPrevious value: -"Number of names to generate (default: 25)"New value: +"Number of names to generate (default: 25, max 30)"Input schema / properties / userIdAdded value: +{
+ "description": "Ignored — derived from your API key",
+ "type": "string"
+}namesniper_trademark1 field changedInput schema / properties / userIdAdded value: +{
+ "description": "Ignored — derived from your API key",
+ "type": "string"
+}namesniper_check1 field changedInput schema / properties / platforms / descriptionPrevious value: -"Social platforms to check (default: all supported platforms)"New value: +"Social platforms to check (default: the standard platform grid; excludes Telegram, pass platforms explicitly including telegram to check it)"namesniper_check_social1 field changedInput schema / properties / platforms / descriptionPrevious value: -"Platforms to check (default: all supported platforms)"New value: +"Platforms to check (default: the standard platform grid; excludes Telegram, pass platforms explicitly including telegram to check it)"namesniper_watch1 field changedInput schema / properties / platforms / descriptionPrevious value: -"Platforms to monitor (default: all supported platforms)"New value: +"Platforms to watch - required; each consumes one watch slot"namesniper_unwatchnamesniper_roblox_raritynamesniper_telegram_pricenamesniper_alternativesnamesniper_checknamesniper_check_domainsnamesniper_check_socialnamesniper_generatenamesniper_trademarknamesniper_watchnamesniper_watchesWatch domains and forecast when they drop; check a name's domain, handles, and trademark.
Check if a brand name is free across domains, GitHub, npm and PyPI, and suggest available names.
Domain availability over RDAP, watchlists with daily checks, change history and email alerts.
Trademark filing monitor across 40+ countries - detect filings that resemble your brand.
Add one secure layer between your agents and this server.
