Enables username availability checking and handle monitoring for Bluesky.
Enables username availability checking and handle monitoring for GitHub.
Enables username availability checking and handle monitoring for Instagram.
Enables username availability checking and handle monitoring for Kick.
Enables username availability checking and handle monitoring for Linktree.
Enables username availability checking and handle monitoring for npm.
Enables username availability checking and handle monitoring for Pinterest.
Enables username availability checking and handle monitoring for Reddit.
Provides Roblox username rarity ratings, availability checks, and handle monitoring.
Enables username availability checking and handle monitoring for Snapchat.
Enables username availability checking and handle monitoring for Substack.
Provides Telegram username market history including peak/latest sale prices in TON and live auction state.
Enables username availability checking and handle monitoring for Threads.
Enables username availability checking and handle monitoring for TikTok.
Uses public TON blockchain records to supply Telegram username market data.
Enables username availability checking and handle monitoring for Twitch.
Enables username availability checking and handle monitoring for YouTube.
NameSniper monitors taken usernames and alerts you the moment one frees up or drops, so you can claim a handle before anyone else. It also checks live handle availability across all the major social platforms, checks domains across popular TLDs, and screens names for trademark conflicts. All from your AI client - Claude, Cursor, or any MCP host.
The server runs remotely at https://namesniper.pro/mcp (Streamable HTTP). Checking and alternatives are free and need no account; name generation, trademark screening, and handle monitoring need a NameSniper API key (Pro or Business plan).
Most availability checkers give a one-time yes or no. NameSniper keeps watching: put a taken handle on watch with namesniper_watch and get notified the instant it frees up across every platform we support, so you can register it first. Every plan includes watch slots (more on paid tiers); Instagram, TikTok, and X monitoring requires a paid plan.
Related MCP server: Social Media Handle Checker
{
"mcpServers": {
"namesniper": {
"url": "https://namesniper.pro/mcp"
}
}
}{
"mcpServers": {
"namesniper": {
"command": "npx",
"args": ["-y", "namesniper-mcp"]
}
}
}With an API key for the paid tools (generate, trademark, watch):
{
"mcpServers": {
"namesniper": {
"command": "npx",
"args": ["-y", "namesniper-mcp"],
"env": { "NAMESNIPER_API_KEY": "ns_sk_your_key_here" }
}
}
}You can also pass the key as a flag: npx namesniper-mcp --key ns_sk_.... Get a key at namesniper.pro/dashboard.
Config file locations:
Claude Desktop: claude_desktop_config.json
Cursor: .cursor/mcp.json
Tool | What it does | API key |
| Name across domains + social, with brand score (trademark screening when authenticated) | Free |
| Domain availability across TLDs | Free |
| Username availability across platforms | Free |
| Brand name variations and creative patterns | Free |
| Telegram username market history: peak/latest sale in TON, live auction state, from public TON blockchain records | Free |
| Roblox username rarity rating from measured namespace data, with live availability | Free |
| AI brand name generation from a description | Required |
| USPTO trademark conflict screening | Required |
| Start monitoring a handle and get notified when it frees up | Required |
| List monitored handles and their status | Required |
| Stop monitoring a handle and free up the watch slot | Required |
Unauthenticated calls are rate limited. Provide an API key for higher limits and the paid tools.
Resource | URI |
Pricing and per-call costs |
|
Supported platforms and TLDs |
|
YouTube, Reddit, TikTok, Instagram, X (Twitter), GitHub, npm, Twitch, Threads, Bluesky, Pinterest, Snapchat, Kick, Substack, Linktree, Roblox.
Website: https://namesniper.pro
API docs: https://namesniper.pro/docs/api
MIT
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 (default: 8) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the transparency burden. It discloses deterministic generation, the exact JSON output shape (alternatives[] with name, pattern, description, score), the 0-100 brandability metric, and that it is free with no API key. This is strong behavioral disclosure beyond basic purpose.
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 deliver the entire needed context: what the tool does, output format, usage guidance, and cost/access constraints. Every clause adds value; no filler or repetition.
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?
Since there is no output schema, the description compensates by specifying the JSON return shape and fields. It also includes usage context, cost/access, and sibling differentiation. This is complete for an agent to invoke correctly without further lookup.
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 descriptions already fully cover both parameters: 'name' is described as 'The base brand name' and 'count' includes a default. The description does not add extra parameter-level meaning, so it stays at the baseline for high schema coverage.
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?
Clear verb 'Generate variations' targeting an existing brand name, explicitly distinguishing from sibling tool namesniper_generate for brand-new AI ideas. Mentions specific patterns (prefix, suffix, compound, wordplay) that define the resource boundary.
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 states when to use this tool ('riff on a name the user already has') and names the alternative (namesniper_generate) for when not to. This leaves no ambiguity about tool selection.
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 | |
| domains | No | TLDs to check (default: com,org,net,app,dev,tech,io,co,ai) | |
| platforms | No | Social platforms to check (default: all supported platforms) | |
| trademark | No | Include trademark screening via USPTO — requires an API key; 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 carries full responsibility for disclosure. It reveals rate-limiting, trademark being skipped without a key, best-effort confidence on Instagram/TikTok/X, and the exact return structure (verdicts, confidence, summaries, brandScore, trademark risk). This goes well beyond basic safety traits.
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 long but every sentence carries unique value: purpose, return format, alternatives, and free/paid limitations. It is front-loaded with the core purpose, though the first sentence is lengthy and could be broken up for easier parsing.
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 no output schema and no annotations, the description covers return format, per-domain/per-platform details, confidence scores, summaries, trademark risk, rate limiting, and authentication requirements. It also names sibling tools for narrower use cases, making it highly complete for a complex all-in-one 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 description coverage is 100%, so the baseline is 3. The description adds slight context by mentioning 'optional 0-100 brand score' and 'USPTO trademark screening' which map to brandScore and trademark, but overall it does not add significant meaning beyond what the schema already 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 clearly states the tool's function with a specific verb and resource: 'All-in-one brand name check' covering domains, social platforms, brand score, and trademark. It distinguishes itself from siblings by explicitly naming alternatives, making its scope unambiguous.
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 states when to use this tool versus alternatives: 'Use namesniper_check_domains or namesniper_check_social instead when only one dimension is needed.' Also provides context on free vs paid usage and trade-offs, which helps an agent decide when this tool is appropriate.
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. 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) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the lookup method (DNS with registry-data fallback), output structure (per-TLD results with confidence score and summary), and operational constraints (free, rate-limited).
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, front-loaded with the core action. Every clause adds value: method, output, comparison to sibling, and constraints. No 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?
Despite lacking an output schema, the description explicitly explains the return format (per-TLD results with confidence and summary). With only two parameters and no annotations, this fully covers behavior and limitations.
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%—both parameters are described in the input schema. The description adds little beyond that, so baseline 3 is appropriate; it doesn't need to repeat schema details.
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?
States a specific verb+resource: 'Check whether a domain name is registered across multiple TLDs.' Clearly distinguishes from sibling tool namesniper_check by noting it is 'Faster and narrower than namesniper_check 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?
Provides explicit when-to-use guidance: 'Faster and narrower than namesniper_check when social handles are not needed.' This also names the alternative tool, making the selection criteria clear.
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 | |
| platforms | No | Platforms to check (default: all supported platforms) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and succeeds. It discloses the JSON return format, per-platform status/confidence scores, rate limits, free vs. paid key behavior, and accuracy caveats for Instagram, TikTok, and X/Twitter. This goes well beyond a simple 'check' statement.
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 dense sentences that front-load the purpose, then cover output format and usage context. Every sentence adds distinct value, with no redundant or vague phrasing.
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 lack of annotations and output schema, the description is remarkably complete. It covers return structure, alternative tool links, rate-limiting, authentication tiers, and accuracy expectations, leaving no critical gaps for an agent to misuse the 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 description coverage is 100%, so the baseline is 3. The description does not add extra detail about the 'name' or 'platforms' parameters beyond what the schema already states; it focuses on tool behavior, not 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 opens with a specific verb and resource: 'Check username availability across the major social platforms concurrently.' It explicitly distinguishes itself from namesniper_check for domain-only needs and references namesniper_watch, making the tool's scope clear relative to 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 explicitly states when to use this tool: 'Narrower than namesniper_check when domains are not needed.' It also provides next-step guidance, suggesting namesniper_watch if a handle is taken, aiding in tool selection.
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) | |
| style | No | Style: modern, classic, tech, creative, professional, playful, abstract, luxury, minimalist | |
| 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 fully carries the burden. It discloses non-determinism, caching with cached:true, latency, return structure (names[] with fields), auth requirements, and quota. This is exceptional behavioral transparency beyond standard 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?
The description is front-loaded with the main purpose, then efficiently covers nontrivial behavior, output, requirements, and an alternative in a few compact sentences. Every sentence provides unique, necessary information 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?
Given that there is no output schema, the description explains the exact JSON return format. It covers purpose, behavior, latency, caching, auth, quota, and alternatives, making it fully self-sufficient for an agent to decide when and how to invoke the 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 description coverage is 100%, so baseline is 3. The description does not add extra semantic detail beyond the schema's parameter descriptions (count, style, description), but it doesn't need to since the schema already explains each param clearly.
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 begins with a specific verb+resource: 'Generate new brand name ideas with AI from a business or project description,' and immediately distinguishes the tool from sibling namesniper_alternatives by stating that the alternative is for riffing on existing names. This clearly identifies the tool's unique function and scope.
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 (to generate names from a description) and names the alternative for when the user already has a name: 'To riff on a name the user already has, use namesniper_alternatives instead.' It also notes requirements (API key, paid plan, daily quota) that affect usage decisions.
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).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The brand name to screen | |
| 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 burden of behavioral disclosure. It reveals the return format (JSON with matching marks and summary with risk rating), the effect of includeVariations (slower, more lookups), the fact that it's not legal advice, and the API key requirement. This is rich, honest context.
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, front-loaded with the core action, and every sentence adds value: what it does, what it returns and the variation trade-off, plus necessary caveats (not legal advice, API key required). No fluff or repetition.
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 having no output schema, the description adequately explains the return content (JSON, matching marks, summary, risk rating). It also covers auth requirements (API key), scope (US), and operational nuance (includeVariations). For a tool with simple parameters and no output schema, this is complete enough for an agent to use 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 the baseline is 3. The description adds meaningful behavioral context for includeVariations (slower, more lookups) and implies the mandatory nature of the name parameter through the screening purpose. This exceeds baseline by adding nuance beyond the schema's simple descriptions.
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 a specific action ('Screen a brand name for US trademark conflicts against the USPTO database with similarity analysis') with an explicit resource (USPTO database). This distinguishes it from sibling tools like namesniper_check_domains or namesniper_check_social, which target different trademark/domain/social 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?
The description establishes a clear use case (US trademark conflict screening) and provides guidance on the optional includeVariations parameter ('slower, more lookups'). However, it does not explicitly contrast with alternative sibling tools, so it earns a 4 rather than a 5.
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?
With no annotations provided, the description carries the full burden. It discloses the return format ('Returns JSON with the removed count and ids'), the auth requirement ('Requires an API key'), and the behavior of removing all watches for a username unless platform is given. It lacks error-condition details or idempotency info, but the essential behavioral traits are 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?
The description is three sentences, front-loaded with the primary purpose. Each sentence adds valuable information: what it does, how to invoke it, and what it returns. There is no fluff or repetition of schema details that are already visible.
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 tool with 4 optional parameters, no required params, no output schema, and no annotations, this description is quite complete. It explains both usage modes, the return value, and the auth requirement. It could mention edge cases like passing both id and username, but that's not necessary for basic invocation; the description 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?
The schema already documents all 4 parameters with 100% coverage, so baseline is 3. The description adds semantic meaning by explaining the relationship between id and username as alternative removal modes, and that platform narrows username-based removal to one platform. This goes beyond individual parameter descriptions.
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 phrase 'Stop monitoring a watched handle and free its slot,' which clearly states the tool's action and resource. It distinguishes from siblings like namesniper_watch (adds a watch) and namesniper_watches (lists watches) by focusing on removal. The two input modes (watch id or username) are also stated clearly.
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 tells users exactly how to invoke the tool: pass a watch id from namesniper_watches, or a username optionally narrowed by platform to remove all its watches. It implies when to use it (when you want to stop monitoring) and distinguishes from the add/list siblings by context. It does not explicitly state when not to use it or name alternatives, but the usage context is clear.
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 the moment it frees up or drops. 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 monitor (default: all supported platforms) |
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 discloses multiple behavioral aspects: creates one watch per platform, enforces slot limits, skips already-watched pairs, runs automatic checks on a schedule, delivers alerts via in-app/email/webhooks, returns JSON with created ids and skipped count, and requires a paid API key. This is exceptionally thorough for a tool description.
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 6 sentences long, but every sentence adds unique value: purpose, operational behavior, scheduling, output, related tools, and auth requirement. It is front-loaded with the primary action and avoids tautology or fluff. The structure is logical and information-dense without being overwrought.
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 tool with no output schema and no annotations, the description is quite complete: it covers the action, prerequisites, side effects, return shape, and related operations. The only gap is the behavior when the plan's slot limit is exceeded (does it error? does it silently fail?), which is a minor omission given the stated slot-limit constraint.
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 input schema already covers all parameters with descriptions (100% coverage), providing a baseline of 3. The tool description adds extra meaning beyond the schema by explaining that 'creates one watch per platform' and 'already-watched pairs are skipped', which clarifies how the platforms parameter behaves in practice. This goes beyond simple schema definitions, justifying 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 begins with a specific verb and resource: 'Start monitoring a taken username so the user can claim it the moment it frees up or drops.' This clearly states the tool's purpose and implies its scope (monitoring, not checking). It also distinguishes itself from siblings by explicitly referring to namesniper_watches (list) and namesniper_unwatch (stop), making the unique role obvious.
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 usage context: it is for taken usernames, creates watches per platform, and mentions the plan-based schedule. It names sibling tools for listing and stopping watches, giving an implicit alternative. However, it does not explicitly say when NOT to use this tool compared to check tools, so it falls short of a perfect score.
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?
With no annotations present, the description carries the behavioral disclosure burden. It reveals the read-only list nature, details the return fields, slot usage, and API key requirement. It does not mention potential errors or rate limits, but covers the essential behavior.
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 long, front-loads the action, and organizes return details and usage guidance efficiently. No filler or redundant content, though the dense field list makes it slightly long.
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?
In the absence of an output schema and annotations, the description compensates by enumerating the returned JSON fields, slot usage, and authentication requirement. It also points to the complementary unwatch tool, giving enough context for correct usage.
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 input schema already documents the sole parameter and states it is ignored/derived from the API key. The description adds no parameter-specific semantics, but the high schema coverage makes this acceptable; baseline 3 applies.
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 a specific action ('List every handle the account is monitoring') with a defined resource. It naturally distinguishes itself from sibling tools like namesniper_watch and namesniper_unwatch.
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?
Provides explicit guidance to use a watch id with namesniper_unwatch for stopping monitoring, and notes the API key requirement. It does not explicitly contrast with check-type siblings, but the list context makes its purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose: check variants are explicitly scoped as all-in-one vs domain-only vs social-only, generate vs alternatives are differentiated by input type, and watch/watches/unwatch form a clean lifecycle. No two tools have ambiguous boundaries.
All tools share the namesniper_ prefix and use snake_case, which is consistent. Most actions are verbs or verb_noun (check, generate, watch), but a few nouns like trademark, alternatives, and watches break the strict pattern, though they are still clear and predictable.
11 tools is well within the ideal range for a domain-specific server. Each tool addresses a distinct need—checking, watching, generating, trademark screening, and niche platform data—without redundancy or bloat.
The tool set provides full lifecycle coverage for brand name monitoring: availability checks, watch creation/listing/removal, name generation, and trademark screening. The specialized Telegram and Roblox tools cover niche use cases, leaving no obvious dead ends.
Watch 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.
Free brand-name Clearance Checks from live registries; connect a plan (API key) for full checks.
Generate startup names with an available .com, checked live, then screen US and EU trademarks.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ArvaNet/NameSniper-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
