Skip to main content
Glama
Sign In
GPX MCP Server

GPX MCP Server

by gpxco
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List account events

list_events
Read-onlyIdempotent

Retrieve account event feeds across all devices within a time window, then filter by device, geofence, shipment, or event type to review geofence entries, exits, alarms, and shipment activity.

Instructions

List account events

Returns the account's event feed across every device (geofence enters and exits, alarms, shipment events) within a time window, 24 hours by default. Filter by device, geofence, shipment or event type; a geofence's enter and exit history is this feed filtered by geofence_id.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_events"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number, starting at 1. Must be at least 1.
sortNoSort on event_at. Prefix with - for descending. Defaults to -event_at.
per_pageNoResults per page. Defaults to 50, capped at 100. Must be at least 1. Must not be greater than 100.
device_idNoRestrict to one device. Must be at least 1.
event_typeNoEvent type (e.g. geofence-exit, alarm-sos, shipment-late). Repeatable. Must not be greater than 128 characters.
event_afterNoStart of the window on event_at. Defaults to 24 hours before event_before when both are omitted, or 30 days before event_before when only event_before is set. Must be a valid date.
geofence_idNoRestrict to events for one geofence. Must be at least 1.
shipment_idNoRestrict to events for one shipment. Must be at least 1.
event_beforeNoEnd of the window on event_at. Defaults to now when omitted, or 30 days after event_after when only event_after is set. Must be a valid date. Must be a date after or equal to <code>event_after</code>.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds useful non-annotation context: the feed spans every device, defaults to a 24-hour window, and expands to 30 days when only one boundary is supplied, which materially affects what an agent will get back.

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?

Two tight sentences with the scope and defaults front-loaded, followed by filtering options and the geofence clarification. The opening line duplicates the title verbatim, which is the only wasted text.

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?

For a read-only filtered list with nine optional parameters, no output schema, and full schema coverage, the description supplies what is needed: what is returned, the default window, the filter axes, and the geofence-to-enter/exit relationship. Nothing required for correct invocation is missing.

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 100%, so the schema already carries defaults, caps, and per-parameter constraints. The description's only genuine semantic addition beyond that is the geofence_id = enter/exit history equivalence; the rest (time window defaults, filters) restates what the schema documents.

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 specific verb and resource ('List account events') and enumerates the event kinds returned (geofence enters/exits, alarms, shipment events) across every device. It never names the closest sibling, list_device_events, so the device-scoped variant is only implicitly distinguished by the 'across every device' phrasing and the device_id filter.

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 states the default time window (24 hours) and the available filter axes (device, geofence, shipment, event type), and it clarifies that a geofence's enter/exit history is simply this feed filtered by geofence_id. That resolves a real routing ambiguity, though there is no explicit when-not-to-use or named alternative tool.

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