Skip to main content
Glama

YouSpot

by com.youspot

Look up domain

get_domain_info
Read-only

Look up the public registration (WHOIS) record for a website domain: who registered it, which registrar holds it, when it was created and last updated, when it expires, its nameservers, and its registry status codes. Use this ONLY when the user explicitly asks about the domain/WHOIS/DNS itself: 'who owns stripe.com?', 'when does our domain expire?', 'how old is this domain?', 'is this domain registered?'. Never call it for general questions about a company — this is public registrar data about a domain on the internet; it is not the user's own account data, and it says nothing about the company behind the domain. Registrant details are often masked by a privacy service, in which case the registrant fields name the proxy rather than the real owner; say so instead of presenting the proxy as the owner.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
domainYesThe domain to look up, e.g. "hubspot.com". A full URL is accepted and reduced to the domain.

Schema Changelog

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

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, the description discloses that this is public registrar data, not the user's account data, and that it says nothing about the underlying company. It also surfaces the privacy-masking behavior where registrant fields may name a proxy rather than the real owner, which is a key behavioral caveat.

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?

Every sentence earns its place: the first defines the operation and outputs, the second gives precise usage rules with examples, the third states a hard exclusion, and the fourth adds the important privacy caveat. It is informative without filler.

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

Completeness5/5

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

For a read-only tool with one required parameter and no output schema, the description covers what the call returns, exactly when to use it, when not to use it, and the main data-quality caveat. Nothing essential for correct invocation is missing.

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 input schema already covers both parameters fully: the single 'domain' parameter has a clear description, an example value, and the full-URL normalization behavior. The tool description adds no additional parameter-level meaning beyond referring to a 'website domain', so the high schema coverage baseline of 3 is appropriate.

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?

States a specific verb and resource: 'Look up the public registration (WHOIS) record for a website domain' and enumerates the exact fields returned. It also contrasts with general company research, which clearly distinguishes it from siblings like research_company and get_domain_value.

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

Usage Guidelines5/5

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

Explicitly scopes usage with 'Use this ONLY when the user explicitly asks about the domain/WHOIS/DNS itself', provides concrete example queries, and gives a hard exclusion: 'Never call it for general questions about a company'. This is exemplary routing guidance.

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

All YouSpot toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool targets a distinct resource and action, with clear boundaries even within overlapping domains like LinkedIn (search vs. free-form query vs. profile vs. summary) and graph deletion (soft single, bulk soft, permanent single). Descriptions explicitly cross-reference related tools to prevent misselection.

Naming Consistency4/5

The vast majority follow a consistent verb_noun pattern (get_, list_, search_, create_, delete_, etc.). A few noun-phrase exceptions like linkedin_analytics, mutual_connections, similar_objects, and what_needs_attention deviate slightly, but they are still descriptive and do not create confusion.

Tool Count2/5

At 66 tools this is far beyond the 25+ threshold considered too many, even though the server covers many integration domains. Each domain has a coherent subset, but the overall surface is heavy for agents to navigate and would benefit from consolidation or namespacing.

Completeness4/5

The set provides deep read/search coverage across Gmail, Slack, Calendar, LinkedIn, HubSpot, Obsidian, Twitter, and a graph store, with core write operations for calendar, drafts, Slack, and graph objects. Minor gaps exist—notably no calendar delete, no direct Gmail send to third parties (only drafts), and no LinkedIn post/message actions—but these appear deliberate and do not block typical workflows.

Resources