Skip to main content
Glama
Sign In
samuelcsantana

pyxis-mcp

by samuelcsantana
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Requests

requests
Read-onlyIdempotent

Retrieves per-route backend call failures and latency for a project and date range, covering non-GET writes and failed GET reads with statuses, median/95th percentile times, screens, and error codes.

Instructions

The site's calls to its own backend, per route: failures, statuses, median and 95th percentile durations, the screens they came from and the latest failures with their error codes. writes covers every non-GET call; reads covers failed GET calls only. 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.
fromYesFirst day of the range, inclusive (YYYY-MM-DD).
kindNowrites (the default) or reads.
routeNoA route also answered day by day: POST /orders/:id.
screenNoOnly the calls made from this page path.
project_idYesThe project id, from list_projects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.3
    • changedInput schema / properties / route / description
      Previous value: -"Also answer this route day by day: POST /orders/:id."New value: +"A route also answered day by day: POST /orders/:id."
  2. First observedv0.4.0

TDQS

A4.7/5.0
Behavior4/5

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

While annotations cover safety, the description adds crucial behavioral context regarding timezone handling and the origin of the data. This informs the agent about the temporal constraints and data reliability of the tool.

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?

The description is highly dense and verbose, but every sentence provides highly valuable operational or constraint information. It sacrifices conciseness for maximum functional clarity, which is justified by the complexity of the tool.

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?

Given the multi-faceted nature of the data (routes, screens, time zones, and call types), the description is exceptionally complete, leaving no ambiguity regarding the tool's scope or data origin.

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 100% schema coverage, the description provides significant added meaning, defining the operational semantics of the 'reads' and 'writes' parameters, and setting strict temporal limits on the date parameters.

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?

The description clearly identifies the resource (site calls to the backend) and the granular data it returns (statuses, durations, error codes). It further differentiates the tool by detailing the specific metrics and scopes covered.

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?

It provides specific usage constraints, such as the date range limit (400 days) and the requirement that the project ID is derived from list_projects. It also defines the operational logic for the 'reads' vs 'writes' kind.

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