Skip to main content
Glama

vebhost_domain_bind

Привязать свой домен к сайту и сразу проверить A-записи.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>",
      "hostname": "<hostname>"
    },
    "name": "vebhost_domain_bind"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYes
hostnameYesДомен без схемы, например studio.ru

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations at all, the description carries the full behavioral burden for a mutation tool. It does not say whether binding is idempotent, what happens if the hostname is already bound to another site, whether the call fails when A-records do not yet resolve, or whether the verification result affects the operation's success. Only the two-step intent is conveyed.

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?

A single front-loaded sentence that combines the action and its side effect with no filler. It is arguably too terse rather than padded, so the structure is good but the sentence does little work beyond stating the headline.

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

Completeness2/5

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

For an unannotated two-parameter mutation with no output schema, an agent needs to know failure modes, DNS prerequisites, and what the A-record check returns. None of that is present, and the undocumented slug parameter compounds the gap.

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

Parameters2/5

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

Schema coverage is 50%: hostname is documented with a concrete example ('studio.ru', no scheme), but slug is a bare string with no description and the tool description never clarifies that it identifies the target site. The description adds no meaning beyond the schema and leaves half the parameters undocumented.

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

Purpose4/5

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

The description gives a specific verb and resource: bind a domain to a site, plus an immediate A-record check. That is far more informative than the name alone. However, it does not distinguish itself from the sibling vebhost_domain_check, which plausibly covers the same DNS verification step, so an agent cannot fully separate the two from this text.

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

Usage Guidelines3/5

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

Usage is implied: use this when you want a domain pointed at a site. There is no explicit when-not guidance, no statement of prerequisites such as owning the domain or having DNS delegated to the host, and no mention of vebhost_domain_check as the alternative for a pure DNS lookup.

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.

Resources