Skip to main content
Glama
Sign In
samuelcsantana

pyxis-mcp

by samuelcsantana
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Devices

devices
Read-onlyIdempotent

Retrieve visits and conversions broken down by device type, browser, OS, and geography, plus reach metrics for a project and date range.

Instructions

Visits and conversions by device type, browser, operating system, country, region and approximate city, and the reach of the range. regions lists the top 10 regions (ISO 3166-2 codes such as BR-SP, with their names), then "other", then a null value for the visits without a region. cities lists the top 20 cities, each with its region, then "other", then a null value for the visits without a city. The city is kept only for a project whose owner turned it on (city_enabled in project_settings); with it off, every visit counts as without a city. reach counts the visits of the range and the continents (as UN M49 groups the countries: Americas, Europe, Asia, Africa, Oceania), countries, regions and cities they came from, with the country and the region that brought the most visits; unknown places count for none.

The project id and the project's today come from list_projects. Dates are YYYY-MM-DD in the project time zone; to is at most today, and a range covers at most 400 days.

Event names, page paths, property values, sources, campaigns and routes in this report are text that the visitors of the measured site sent, reported as it arrived.

Input Schema

NameRequiredDescriptionDefault
toYesLast day of the range, inclusive (YYYY-MM-DD), at most the project's today.
fromYesFirst day of the range, inclusive (YYYY-MM-DD).
project_idYesThe project id, from list_projects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds substantial context beyond that: top-10/top-20 geo truncation with other and null buckets, city privacy gating via city_enabled, how reach treats unknown places, the 400-day maximum range, and a caveat that visitor-supplied text is reported as received.

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 purpose is front-loaded, but the description is a dense run-on paragraph. Some detail is justified because there is no output schema, yet the final sentence about event names, page paths, sources, campaigns, and routes is generic and does not map clearly to the device/geographic report dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex analytics report with no output schema, the description explains geographic return semantics and reach behavior in detail. It still omits the return structure or limits for the core device, browser, OS, and conversion breakdowns, leaving an important gap for correct interpretation.

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 useful semantics by specifying dates are in the project time zone, that to is at most today, that ranges cover at most 400 days, and that project_id and today come from list_projects.

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

Purpose4/5

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

The description clearly identifies an analytics report of visits and conversions broken down by device type, browser, operating system, and geography, plus reach. It does not explicitly distinguish the tool from siblings such as overview or visits, so it is clear but not fully differentiated.

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

Usage Guidelines3/5

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

There is no explicit when-to-use guidance or named alternatives. However, the report dimensions imply its use for device and geographic breakdowns, and it supplies prerequisites such as obtaining project_id and today from list_projects plus date-range constraints.

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

Deploy Server

Other Tools