Skip to main content
Glama
minanyang

Nameable

by minanyang
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Check name availability

check_names
Read-onlyIdempotent

Check whether project or package names are free across package registries, GitHub, app stores, plugin directories, and domains, with status and evidence for each candidate.

Instructions

Check whether names are free on package registries, GitHub, agent and editor directories, app stores and domains.

Each result has a status:

  • available: nobody holds it and the registry would accept it. certainty "confirmed" means every rule that public data allows was checked; "probable" means one could not be, and note says which.

  • reclaimable: held before but released; it can be taken again.

  • taken: someone holds it; url shows who. Where names are not exclusive (MCP Registry, Google Play, Gemini CLI gallery) it means another entry uses the name, and note says it does not block a new one.

  • unavailable: nobody holds it exactly, but the registry would refuse it (invalid, reserved, too similar to an existing name, or blocked for now after a deletion); note says why.

  • unknown: no trustworthy answer (network error, rate limit). Never treat it as free.

Pick only the channels that matter for the project instead of checking everything.

Input Schema

NameRequiredDescriptionDefault
tldsNoTLDs for "domain", at most 20 (default: com, dev)
namesYesCandidate names, checked on every selected channel
refreshNoDownload registry name lists again even when the cached copy is fresh
channelsNoChannels to check (default: all). One of: npm, pypi, crates, homebrew, rubygems, packagist, pub, nuget, docker, github, mcp-registry, smithery, claude-plugins, cursor, gemini, vscode, open-vsx, jetbrains, app-store, google-play, domain, domain:<tld>. "domain" means every TLD in tlds.

Output Schema

NameRequiredDescriptionDefault
schemaYes
reportsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.1.0
    • removedInput schema / properties / channels / minItems
      Removed value: -1
    • removedInput schema / properties / tlds / minItems
      Removed value: -1
  2. First observedv2.0.2

TDQS

A4.5/5.0
Behavior5/5

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

Far beyond the annotations (which only say read-only, idempotent, open-world), it documents the meaning of each status value, explains the 'confirmed' vs 'probable' certainty distinction, clarifies that non-exclusive registries don't block a new name, and warns 'Never treat unknown as free.' That is exactly the behavioral context an agent needs to interpret results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

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

The purpose sentence is front-loaded, followed by a structured status list that earns its space given how many result states exist. Some lines are dense and wrap across sentences, but nothing is filler.

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

Completeness4/5

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

With an output schema present, the description needn't explain return values, yet it explains result semantics anyway, which is a genuine surplus. It lacks explicit edge-case guidance on large name lists or rate limits, but that is minor against the otherwise thorough coverage.

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

Parameters4/5

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

Schema coverage is 100%, so the schema already documents all four parameters well. The description adds little parameter-specific detail, but it reinforces the channel-selection semantics that govern 'channels', 'tlds', and 'refresh' behavior, which is modest value above the schema baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Check whether names are free on package registries, GitHub, agent and editor directories, app stores and domains.' The channel set is enumerated, so an agent knows exactly the scope of the check without opening the schema.

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

Usage Guidelines4/5

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

It gives clear operational guidance: 'Pick only the channels that matter for the project instead of checking everything,' which is a real usage constraint. It doesn't spell out when another tool should be used instead, but no siblings exist, so the exclusion gap is structural rather than a description failure.

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

Deploy Server

Other Tools