get_visitorsRecent individual visits: entry page, path taken, country, device, human/bot.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| days | No | ||
| from | No | YYYY-MM-DD | |
| site | Yes | ||
| limit | No | ||
| before | No | Page further back: the last_seen of the last row you got; a page shorter than limit is the end | |
| filters | No | Narrow the report to the visits that match ALL of these (the dashboard's click-to-filter), inside the same window as the report. Omit for everything. |
Changes observed during successful MCP inspections.
Input schema / properties / filtersAdded value: +{
+ "additionalProperties": false,
+ "description": "Narrow the report to the visits that match ALL of these (the dashboard's click-to-filter), inside the same window as the report. Omit for everything.",
+ "properties": {
+ "browser": {
+ "description": "Browser name as get_breakdown dimension=browsers lists it",
+ "type": "string"
+ },
+ "campaign": {
+ "description": "utm source|medium|campaign exactly as a get_breakdown dimension=campaigns row; an empty part matches any, e.g. newsletter||",
+ "type": "string"
+ },
+ "country": {
+ "description": "ISO 3166-1 alpha-2 code, e.g. US; several joined with |, e.g. US|DE",
+ "type": "string"
+ },
+ "device": {
+ "description": "Device class as get_breakdown dimension=devices lists it (desktop, mobile, tablet)",
+ "type": "string"
+ },
+ "event": {
+ "description": "Visits that fired this custom event name (get_events lists the names)",
+ "type": "string"
+ },
+ "goal": {
+ "description": "Visits that completed this saved goal, by the id get_goals returns",
+ "type": "string"
+ },
+ "os": {
+ "description": "Operating system as get_breakdown dimension=os lists it",
+ "type": "string"
+ },
+ "page": {
+ "description": "Visits that viewed this page path, e.g. /pricing",
+ "type": "string"
+ },
+ "referrer": {
+ "description": "Visits that arrived from this referrer host, e.g. google.com",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Input schema / properties / beforeAdded value: +{
+ "description": "Page further back: the last_seen of the last row you got; a page shorter than limit is the end",
+ "type": "string"
+}Input schema / properties / fromAdded value: +{
+ "description": "YYYY-MM-DD",
+ "type": "string"
+}Input schema / properties / toAdded value: +{
+ "type": "string"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context about the returned visit fields, but it does not explain pagination behavior, default time windows, or limits beyond what the schema partially covers.
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 a single front-loaded fragment with no wasted words. It is appropriately concise, though its extreme terseness leaves important usage and behavioral details unstated.
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 7 parameters, nested filters, no output schema, and only minimal annotations, the description is too sparse. It lists returned fields but omits date-range defaults, pagination expectations, filtering behavior, and guidance for a required site parameter.
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 only 43%, and the description adds no parameter meaning at all. Top-level parameters like site, days, to, and limit are undocumented, while some nested filter fields are described in the schema; the description fails to compensate for the low coverage.
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 clearly identifies the resource as recent individual visits and lists the key fields returned: entry page, path, country, device, and human/bot. It is specific enough to distinguish a raw visit log from aggregate tools, though it does not explicitly contrast itself with siblings like get_realtime or get_breakdown.
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?
There is no guidance on when to use this tool versus alternatives such as get_realtime, get_stats, or get_paths. The word 'recent' is vague and the description provides no inclusion/exclusion criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.