kinsta_analytics_top-referrersRetrieve top referring domains for a Kinsta site's analytics. Filter by time span or custom date range to identify traffic sources.
Get top referrers.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Custom end date (YYYY-MM-DD) | |
| from | No | Custom start date (YYYY-MM-DD) | |
| env_id | Yes | The environment ID | |
| time_span | No |
Changes observed during successful MCP inspections.
v1.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, which cover the safety profile. The description adds no behavioral context beyond the bare action; it does not mention what the output looks like, any rate limits, or data scope. With annotations present, the description is expected to add some context, but it contributes nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence with no wasted words, which is good for conciseness. However, it is under-specified for a tool with four parameters and a family of similar analytics tools. It lacks structure such as examples or additional context, making it borderline between adequate and too terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and four parameters, the description does not explain return values, pagination, or how to interpret results. It also does not help an agent distinguish this from the many other analytics siblings. Given the complexity of the domain, the description is incomplete for correct invocation and result interpretation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75% (to, from, env_id have descriptions; time_span only has an enum). The description does not add any parameter meaning beyond the schema. Since coverage is high, the baseline is 3, and the description does not compensate for the missing time_span description, but it also does not need to given the enum values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get top referrers.' clearly states the verb (Get) and resource (top referrers), making the purpose unambiguous. It does not explicitly differentiate from sibling analytics tools like top-countries or top-uas, but the resource name itself is specific enough. It is not a tautology and is more informative than just the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other analytics tools (e.g., top-countries, top-uas). The description does not mention alternatives, exclusions, or context such as needing an env_id. The only implied usage is for retrieving referrer data, but there is no explicit routing or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.