Skip to main content
Glama
Sign In
samuelcsantana

pyxis-mcp

by samuelcsantana
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Visits

visits
Read-onlyIdempotent

Browse and filter a project's browser sessions by date range and criteria such as source, campaign, country, route, and events; returns entry pages, views, failures, and totals.

Instructions

The visits of a range, newest first, 50 a page, each with its entry page, page views, first named events, failed requests, source, campaign, country, region and approximate city (null unless the project keeps the city), plus the total of matching visits. A visit is one browser tab; nothing links two of them unless the site identified the person. Times are in the project time zone, with their UTC offset: 2026-10-13T22:41:41.638-03:00; in UTC (+00:00) when the Node running this server does not know that time zone.

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.
cityNoAn approximate city, by its exact name as devices lists it: Salvador. Needs region, since the same name exists in several regions.
fromYesFirst day of the range, inclusive (YYYY-MM-DD).
eventNoA named event the visit sent.
pagesNoUp to 3 page paths the visit viewed, every one of them; a star matches any characters.
routeNoA request the visit made: POST /orders/:id.
cursorNoThe next_cursor of the previous page.
deviceNo
failedNotrue: the visit had a failed request; with route, on that route.
regionNoISO 3166-2 region code: BR-SP.
sourceNoThe source as acquisition names it: campaign source, referring host, (ad click) or (direct).
channelNo
countryNoTwo-letter country code: BR.
campaignNoThe utm_campaign.
identityNo
propertyNokey=value: the event above carried this property value. Needs event.
project_idYesThe project id, from list_projects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.6.1
    • addedInput schema / properties / city
      Added value: +{
+  "description": "An approximate city, by its exact name as devices lists it: Salvador. Needs region, since the same name exists in several regions.",
+  "maxLength": 100,
+  "minLength": 1,
+  "type": "string"
+}
  2. First observedv0.4.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, so the description uses its space well: it discloses ordering (newest first), page size (50), cursor-based pagination, time-zone offset behavior including a UTC fallback when the host lacks the zone, that city is null unless the project retains it, and that filterable text is visitor-supplied and reported verbatim. These are real behavioral traits an agent could not infer from structured fields.

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

Conciseness4/5

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

Front-loaded with the core answer (what you get, in what order, at what page size), followed by constraints and then caveats. The opening sentence is long because it enumerates every returned field, which borders on dumping schema-level detail into prose, but nothing is truly redundant.

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

Completeness4/5

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

For a 17-parameter, no-output-schema read tool, the description covers scope, ordering, pagination, time-zone semantics, and data-quality caveats. It stops short of explaining how next_cursor is surfaced in the response or how filters compose (AND vs OR), which an agent must know to page and combine filters correctly.

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 82%, so the schema already documents nearly every one of the 17 parameters, including the cross-field dependencies (city needs region, property needs event). The description adds only the provenance of project_id/today and the date format/limit, which is modest value on top of an already well-documented schema — baseline 3.

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 first sentence states precisely what is returned: visits over a range, newest first, 50 per page, with an explicit enumeration of the fields each visit carries plus the match total. It is clearly a paginated visit-listing tool, distinguishable from aggregation siblings like acquisition or devices, though it never names a sibling to clarify boundaries.

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?

It supplies real operating context — project id and the project's today must come from list_projects, dates are YYYY-MM-DD in project time zone, to is capped at today, ranges max 400 days. What is missing is when-to-use-this-vs-alternatives guidance: an agent cannot tell from the description why it would pick visits over requests, visit_timeline, or acquisition.

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