Skip to main content
Glama

Vee3

by io.github.Vee3io
OverviewAdmin

google-search-console.add_site

Add a domain as a Google Search Console property on Vee3's Search Console account.

The user or agent can pass a domain, a domain property, or a URL. Vee3-managed domains are added and verified automatically. If the apex host uses URL forwarding, Vee3 writes a Google DNS CNAME record instead of a TXT record. If Google still needs time to verify, the response asks the agent to wait and retry this tool. If Vee3 cannot write DNS, the response includes dns_host_name, dns_record_type, and dns_token. Domains that are not managed by Vee3 return DNS TXT instructions so the user or agent can prove ownership, then retry this tool.

After a site is added, call google-search-console.list_sites to see it, then use the other Search Console tools.

Cost = 10 tokens.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
site_urlYesDomain or property to add. The user or agent passes a hostname (example.com), a domain property (sc-domain:example.com), or a URL (https://example.com/).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoadded, already_added, pending_verification (wait and retry), or needs_verification (create the DNS record in this response, then retry).
messageNoWhat happened and what the user or agent should do next.
site_urlNoNormalized Search Console domain property URL.
dns_tokenNoDNS record value to create when status is needs_verification.
is_managedNoTrue when the domain is a Vee3-managed domain for this account.
domain_nameNoNormalized domain name for the property.
dns_host_nameNoDNS host to create when status is needs_verification. @ for TXT, or the Google CNAME host for domain properties that cannot use an apex TXT record.
dns_record_typeNoDNS record type to create when status is needs_verification. TXT or CNAME.

Schema Changelog

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

  1. Changed4 schema fields changed
    • changedOutput schema / properties / dns_host_name / description
      Previous value: -"DNS host to create when status is needs_verification. Always @."New value: +"DNS host to create when status is needs_verification. @ for TXT, or the Google CNAME host for domain properties that cannot use an apex TXT record."
    • changedOutput schema / properties / dns_record_type / description
      Previous value: -"DNS record type to create when status is needs_verification. Always TXT."New value: +"DNS record type to create when status is needs_verification. TXT or CNAME."
    • changedOutput schema / properties / dns_token / description
      Previous value: -"DNS TXT record value to create when status is needs_verification."New value: +"DNS record value to create when status is needs_verification."
    • changedOutput schema / properties / status / description
      Previous value: -"added, already_added, pending_verification (wait and retry), or needs_verification (add the DNS TXT record, then retry)."New value: +"added, already_added, pending_verification (wait and retry), or needs_verification (create the DNS record in this response, then retry)."
  2. Added

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the full burder of behavioral disclosure. It explains automatic vs. manual verification, CNAME vs. TXT record handling, retry behavior when Google needs time, failure mode when DNS cannot be written, and next steps for unmanagoed domains. This is rich, actionable behavioral detail.

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 dense but every sentence earns its place: purpose, input formats, verification branches, failure handling, retry instructions, and next steps. It is front-loaded with the core purpose and stays focused without fluff.

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?

Covers all relevant branches for managed, unmanaged, forwarding, pending verification, and DNS failure cases. The output schema exists and costs is stated. Nothing an agent needs to know to call it correctly 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?

Schema coverage is 100% and the schema already describes the accepted formats as hostname, domain property, or URL. The description repeats this without adding new param-specific meaning beyond what the schema provides. A score of 3 aligns with the baseline for high schema coverage.

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 first sentence states exactly what the tool does: 'Add a domain as a Google Search Console property on Vee3's Search Console account.' This is a specific verb plus resource and scope. It clearly distinguishes from sibling tools like list_sites and get_site because it is the addition action.

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 gives clear context for when to use the tool and what happens next: after adding, call list_sites and then use other Search Console tools. It does not explicitly state when not to use it, but it has enough procedural guidance to route an agent correctly.

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

All Vee3 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.

Resources