Skip to main content
Glama

domains.get_managed

Get full details for one domain this Vee3 account owns or manages.

Returns registration status, expiration, privacy, DNS provider type, and registration metadata.

Cost = 3 tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesManaged domain name to look up (for example example.com).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainNoManaged domain name.
statusNoCurrent domain status in Vee3 inventory.
is_ownerNoWhether this Vee3 account is the domain owner.
is_lockedNoWhether registrar transfer lock is enabled.
created_atNoWhen the domain was registered through Vee3.
expires_atNoDomain expiration timestamp.
is_premiumNoWhether the domain was registered as a premium name.
privacy_enabledNoWhether WhoisGuard privacy protection is enabled.
years_registeredNoRegistration term in years at purchase.
dns_provider_typeNoDNS provider type configured for the domain.
privacy_expired_atNoWhen privacy protection expired, if applicable.
namecheap_domain_idNoNamecheap domain identifier for the managed domain.
token_cost_at_registrationNoTokens charged when the domain was registered.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and adds useful behavioral details: it enumerates the returned data categories (registration status, expiration, privacy, DNS provider type, registration metadata) and discloses token cost. It does not explicitly state read-only or error behavior, but the 'Get' verb and output focus make this sufficiently clear.

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

Conciseness5/5

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

The description is three short, front-loaded sentences: the core action, the return categories, and the cost. Every sentence provides distinct value with no redundancy or 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?

For a simple one-parameter lookup with an output schema, the description covers purpose, domain ownership scope, return categories, and cost. It does not mention alternatives or error cases, but those are not critical given the tool's low complexity and schema richness.

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

Parameters3/5

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

The schema covers the domain parameter 100%, so the baseline is 3. The description adds minimal extra meaning beyond the schema, only reinforcing that the domain must be owned or managed.

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 states 'Get full details for one domain this Vee3 account owns or manages,' using a specific verb and clear resource scope. It distinguishes this from listing tools like domains.list_managed and general lookup tools.

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?

The description clearly implies use when needing full details for a single domain owned or managed by the account. It does not explicitly name alternative tools or exclusionary cases, but the context is strong enough to guide selection.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation5/5

Each tool has a distinct purpose, further clarified by group prefixes and clear descriptions. Within each group, tools perform different operations (e.g., domains.lookup vs. domains.whois vs. domains.rdap) with no ambiguity.

Naming Consistency5/5

All tools follow a consistent group.tool_name pattern using snake_case. The naming is predictable and uniformly applied across all groups.

Tool Count4/5

78 tools is high, but the server aggregates multiple distinct API domains (11 groups). Each group has a reasonable number of tools, typically under 10, with TikTok having 17. The count reflects breadth, not bloat.

Completeness5/5

Each domain's tool set covers the primary expected operations (e.g., search, details, reviews, metrics, user info). There are no obvious gaps for read-only analytical use; features like posting are likely out of scope.