Flowsery

Get Visitors by Device

get_devices

Read-only

Get visitors split by device type (Desktop, Mobile, Tablet), ranked by visitors descending, for a date range. Use this for the mobile-versus-desktop question; use get_browsers or get_operating_systems for the software split. Pass filter_device to any other tool to restrict it to one device type instead. Three rows at most, so pagination rarely matters. Rows carry value, visitors, revenue, and percentage. Dates default to the last 30 days; all filter_* arguments apply. Requires websiteId or domain with a workspace token.

Input Schema

TableJSON Schema

Name	Required	Description
`endAt`	No	ISO 8601 end of the reporting window (e.g. "2026-01-31"). Defaults to now.
`limit`	No	Max rows to return (1-1000, default 100).
`domain`	No	Website domain from list_websites (e.g. "example.com"). Alternative to websiteId with a workspace token.
`offset`	No	Rows to skip for pagination (default 0). Compare offset + limit against pagination.total in the response.
`startAt`	No	ISO 8601 start of the reporting window, date or datetime (e.g. "2026-01-01" or "2026-01-01T00:00:00Z"). Defaults to 30 days ago.
`timezone`	No	IANA timezone used to bound and bucket the window (e.g. "America/New_York"). Defaults to the website timezone from get_metadata.
`filter_os`	No	Filter by operating system name as returned by get_operating_systems (e.g. "iOS")
`websiteId`	No	Website ID from list_websites. Required with a workspace token unless domain is given; ignored with a website key.
`filter_ref`	No	Filter by ref URL parameter
`filter_via`	No	Filter by via URL parameter
`filter_city`	No	Filter by city name as returned by get_cities
`filter_goal`	No	Filter to visitors who completed this goal name (as returned by get_goals)
`filter_page`	No	Filter by page path as returned by get_pages (e.g. "/pricing")
`workspaceId`	No	Workspace to act in: an id from list_workspaces. Omit to use the default workspace. Use the same workspaceId for every call about the same workspace, since ids from one workspace do not exist in another
`filter_device`	No	Filter by device type as returned by get_devices: "Desktop", "Mobile" or "Tablet". Matching is case-sensitive.
`filter_region`	No	Filter by region name as returned by get_regions (e.g. "California")
`filter_source`	No	Filter by source URL parameter
`filter_browser`	No	Filter by browser name as returned by get_browsers (e.g. "Chrome")
`filter_channel`	No	Filter by marketing channel as returned by get_channels (e.g. "Organic Search")
`filter_country`	No	Filter by country name as returned by get_countries (e.g. "United States"). Every filter_* value accepts the same operators: "v" is, "!v" is not, "~v" contains, "!~v" does not contain, "a\|b" any of. Filters combine with AND.
`filter_hostname`	No	Filter by hostname as returned by get_hostnames (e.g. "app.example.com")
`filter_referrer`	No	Filter by referrer as returned by get_referrers: a source name such as "Google" for recognized sites, otherwise the domain
`filter_utm_term`	No	Filter by UTM term
`filter_entry_page`	No	Filter by entry/landing page
`filter_utm_medium`	No	Filter by UTM medium
`filter_utm_source`	No	Filter by UTM source
`filter_utm_content`	No	Filter by UTM content
`filter_utm_campaign`	No	Filter by UTM campaign

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	No	Object with status, data (up to three rows, Desktop, Mobile, Tablet, with value, visitors, revenue, percentage), and pagination.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 28, 2026

removedInput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

removedOutput schema / $schema

Removed value: -"http://json-schema.org/draft-07/schema#"

Changed4 schema fields changedSep 27, 2026

changedInput schema / properties / filter_device / description

Previous value: -"Filter by device type: desktop, mobile, tablet"New value: +"Filter by device type as returned by get_devices: \"Desktop\", \"Mobile\" or \"Tablet\". Matching is case-sensitive."

changedInput schema / properties / filter_referrer / description

Previous value: -"Filter by referrer domain as returned by get_referrers (e.g. \"google.com\")"New value: +"Filter by referrer as returned by get_referrers: a source name such as \"Google\" for recognized sites, otherwise the domain"

changedInput schema / properties / filter_region / description

Previous value: -"Filter by region code as returned by get_regions (e.g. US-CA)"New value: +"Filter by region name as returned by get_regions (e.g. \"California\")"

changedOutput schema / properties / result / description

Previous value: -"Object with status, data (up to three rows, desktop, mobile, tablet, with value, visitors, revenue, percentage), and pagination."New value: +"Object with status, data (up to three rows, Desktop, Mobile, Tablet, with value, visitors, revenue, percentage), and pagination."

Changed1 schema field changedSep 27, 2026

addedInput schema / properties / workspaceId

Added value: +{
+  "description": "Workspace to act in: an id from list_workspaces. Omit to use the default workspace. Use the same workspaceId for every call about the same workspace, since ids from one workspace do not exist in another",
+  "type": "string"
+}

Changed18 schema fields changedSep 8, 2026

changedInput schema / properties / domain / description

Previous value: -"Website domain to query. Required when using a workspace token unless websiteId is provided."New value: +"Website domain from list_websites (e.g. \"example.com\"). Alternative to websiteId with a workspace token."

changedInput schema / properties / endAt / description

Previous value: -"ISO 8601 end date (e.g. \"2026-01-31\")"New value: +"ISO 8601 end of the reporting window (e.g. \"2026-01-31\"). Defaults to now."

changedInput schema / properties / filter_browser / description

Previous value: -"Filter by browser name"New value: +"Filter by browser name as returned by get_browsers (e.g. \"Chrome\")"

changedInput schema / properties / filter_channel / description

Previous value: -"Filter by marketing channel"New value: +"Filter by marketing channel as returned by get_channels (e.g. \"Organic Search\")"

changedInput schema / properties / filter_city / description

Previous value: -"Filter by city"New value: +"Filter by city name as returned by get_cities"

changedInput schema / properties / filter_country / description

Previous value: -"Filter by country"New value: +"Filter by country name as returned by get_countries (e.g. \"United States\"). Every filter_* value accepts the same operators: \"v\" is, \"!v\" is not, \"~v\" contains, \"!~v\" does not contain, \"a|b\" any of. Filters combine with AND."

changedInput schema / properties / filter_goal / description

Previous value: -"Filter by goal name"New value: +"Filter to visitors who completed this goal name (as returned by get_goals)"

changedInput schema / properties / filter_hostname / description

Previous value: -"Filter by hostname"New value: +"Filter by hostname as returned by get_hostnames (e.g. \"app.example.com\")"

changedInput schema / properties / filter_os / description

Previous value: -"Filter by operating system"New value: +"Filter by operating system name as returned by get_operating_systems (e.g. \"iOS\")"

changedInput schema / properties / filter_page / description

Previous value: -"Filter by page path"New value: +"Filter by page path as returned by get_pages (e.g. \"/pricing\")"

changedInput schema / properties / filter_referrer / description

Previous value: -"Filter by referrer domain"New value: +"Filter by referrer domain as returned by get_referrers (e.g. \"google.com\")"

changedInput schema / properties / filter_region / description

Previous value: -"Filter by region"New value: +"Filter by region code as returned by get_regions (e.g. US-CA)"

changedInput schema / properties / limit / description

Previous value: -"Max results (1-1000, default: 100)"New value: +"Max rows to return (1-1000, default 100)."

changedInput schema / properties / offset / description

Previous value: -"Pagination offset (default: 0)"New value: +"Rows to skip for pagination (default 0). Compare offset + limit against pagination.total in the response."

changedInput schema / properties / startAt / description

Previous value: -"ISO 8601 start date (e.g. \"2026-01-01\")"New value: +"ISO 8601 start of the reporting window, date or datetime (e.g. \"2026-01-01\" or \"2026-01-01T00:00:00Z\"). Defaults to 30 days ago."

changedInput schema / properties / timezone / description

Previous value: -"IANA timezone (e.g. \"America/New_York\"). Falls back to site default."New value: +"IANA timezone used to bound and bucket the window (e.g. \"America/New_York\"). Defaults to the website timezone from get_metadata."

changedInput schema / properties / websiteId / description

Previous value: -"Website ID to query. Required when using a workspace token unless domain is provided."New value: +"Website ID from list_websites. Required with a workspace token unless domain is given; ignored with a website key."

changedOutput schema / properties / result / description

Previous value: -"Device types (desktop, mobile, tablet) with visitor counts."New value: +"Object with status, data (up to three rows, desktop, mobile, tablet, with value, visitors, revenue, percentage), and pagination."

First observedSep 1, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already establish readOnly/no-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: cardinality ('three rows at most, so pagination rarely matters'), default window (last 30 days), that all filter_* arguments apply, and the auth requirement (websiteId or domain with a workspace token). It stops short of explaining how results are bucketed or what happens with timezone edge cases.

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?

Front-loaded with the core purpose, then routing, then operational caveats. Every sentence carries distinct information — no filler, no restatement of the tool name.

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?

With an output schema present the description need not explain return shape, yet it still flags that rows carry value/visitors/revenue/percentage and that cardinality is bounded. Auth requirements, defaults, and scope are all covered for a 28-param tool, leaving nothing an agent must guess before calling.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3. The description still adds value by noting date defaults and that every filter_* argument applies, and by reframing filter_device as a cross-tool switch rather than just this tool's own filter. That is meaningful semantics beyond the per-parameter schema text.

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?

States a specific verb and resource (get visitors split by device type), names the exact dimension values, the ranking order, and the time scoping. It explicitly separates itself from get_browsers and get_operating_systems, so an agent can route correctly without opening any schema.

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

Usage Guidelines5/5

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

Explicit routing guidance: 'Use this for the mobile-versus-desktop question; use get_browsers or get_operating_systems for the software split.' It also tells the agent the alternative pattern (pass filter_device to another tool) when a single device slice is wanted rather than a breakdown.

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

All Flowsery tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?