Skip to main content
Glama
Sign In
samuelcsantana

pyxis-mcp

by samuelcsantana
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Property summary

property_summary
Read-onlyIdempotent

Calculates median, 25th, and 75th percentiles for a numeric event property, overall and split by another property, so you can summarize distributions like reading time by post.

Instructions

The median, 25th and 75th percentiles of one numeric property of a named event, overall and split by another property of the same event. It answers questions such as how long people read each article: the median of seconds on article_read_100, split by post. Only events whose property is a JSON number count: overall.events says how many, and the figures are null when none does. With by, groups holds the 10 values of that property carried by the most events, and other_count counts the events of every other value; events without it count in overall only. The visit filters keep only the events of the visits that match all of them.

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
byNoAnother property of the same event to split the figures by: post.
osNo
toYesLast day of the range, inclusive (YYYY-MM-DD), at most the project's today.
keyYesThe numeric property to sum up: seconds.
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).
eventYesThe named event whose property to sum up: article_read_100.
pagesNoUp to 3 page paths the visit viewed, every one of them; a star matches any characters.
deviceNo
failedNotrue: only the visits with a failed request.
regionNoISO 3166-2 region code: BR-SP.
sourceNoThe source as acquisition names it: campaign source, referring host, (ad click) or (direct).
browserNo
channelNo
countryNoTwo-letter country code: BR.
campaignNoThe utm_campaign.
identityNo
project_idYesThe project id, from list_projects.
visit_eventNoOnly the visits that sent this named event.
visit_propertyNokey=value: visit_event carried this property value. Needs visit_event.

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. Addedv0.5.0

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the read-only/idempotent annotations, it discloses important behavior: only events whose property is a JSON number count, figures are null when none qualify, 'by' returns the top 10 values plus other_count, and events lacking the property appear in overall only. It also states date bounds (to <= today, max 400 days) and warns that names/paths/values are visitor-supplied text.

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?

It is front-loaded with the core computation before filtering and date caveats, and each sentence carries information. The closing paragraph on visitor-supplied text is a bit of an aside but still earns its place as a data-provenance warning.

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 20-parameter aggregation tool with no output schema, the description explains the key result shape (overall.events, groups, other_count) and filtering semantics well. It stops short of describing the full output structure or parameter interactions for every visit filter, leaving some gaps.

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

Parameters5/5

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

Despite 75% schema coverage, the description adds semantics the schema lacks: 'by' produces top-10 groups with an aggregated other_count, visit filters are conjunctive ('keep only the events of the visits that match all of them'), and the date/time-zone rules are spelled out. This meaningfully extends the parameter documentation.

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 gives a concrete computation (median, 25th and 75th percentiles of one numeric property of a named event) plus its scope (overall and split by another property), which lets an agent tell it apart from a plain counts tool. It never names a sibling, so differentiation is implicit rather than explicit.

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

Usage Guidelines4/5

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

It frames the tool around concrete questions ('how long people read each article') and points to list_projects for the project id, which gives clear usage context. It offers no explicit when-not conditions or named alternatives among the many sibling report tools.

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