Skip to main content
Glama

AIsa Sales

Website Subdomains

get_similarweb_subdomains
Read-onlyIdempotent

Website Subdomains. Response follows the SimilarWeb v5 envelope (meta + data).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitYesNumber of rows to return; max 20, billed as 20 if exceeded.
domainYesTarget domain, e.g. example.com.
offsetNoRow offset for pagination.
countryNoTwo-letter country code. Allowed: us, ww. Default: ww. Coverage is limited to ww and us on the current plan.ww
end_dateYesEnd month, format YYYY-MM.
start_dateYesStart month, format YYYY-MM.
web_sourceNoTraffic source device split. Allowed: desktop, mobile_web, total.
granularityNoTime granularity. Allowed: monthly.
traffic_sourceNoTraffic-source filter.
main_domain_onlyNoRestrict to the main domain only (true/false).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

C2.3/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile and data volatility. The description adds the note that the response follows the SimilarWeb v5 envelope (meta + data), which is a useful behavioral detail about the response structure but not about side effects or call behavior. It does not mention pagination, rate limits, or any other operational aspects, but annotations carry the main burden. This is a minimal but acceptable contribution.

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

Conciseness3/5

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

The description is extremely short, but it is not well-structured. The first sentence 'Website Subdomains' is redundant with the tool name and title, wasting a sentence. The second sentence about the response envelope is useful but minimal. Overall it is concise in length but not optimally front-loaded; the redundant phrase dilutes the value. A tighter description would start with the envelope note and perhaps add a verb phrase. Score 3 reflects acceptable conciseness with a redundant element.

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?

With 10 parameters, 4 required, and a complex domain like SimilarWeb, the description is severely lacking. It provides almost no context beyond the schema: no mention of date format requirements (though schema has it), no explanation of the limit billing behavior, no coverage limitations (though schema mentions country coverage), and no typical use scenarios. The output schema exists, so return values are covered, but the description fails to help an agent understand when and how to use this tool effectively. It is not complete for a tool of this complexity.

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 description coverage is 100%, so every parameter (limit, domain, offset, country, end_date, start_date, web_source, granularity, traffic_source, main_domain_only) already has a description in the schema. The tool description adds nothing about parameters beyond the schema. The baseline is 3 because the schema does the heavy lifting, and the description does not compensate for any missing nuance.

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

Purpose2/5

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

The description 'Website Subdomains' is a noun phrase that merely echoes the tool name and title. It does not state a specific verb or resource, and it does not differentiate this tool from the many similar get_similarweb_* siblings. The only additional detail is about the response envelope, which is about output format, not the core purpose. An agent would have to infer from the name alone that this retrieves subdomains for a domain.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool versus alternatives like get_similarweb_similar_sites, get_similarweb_website_traffic_snapshot, or other SimilarWeb endpoints. No context is given about typical use cases, prerequisites (e.g., domain must exist in SimilarWeb), or conditions that would select this tool over siblings. The agent receives no help in choosing among the many get_similarweb_* tools.

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