Skip to main content
Glama
Sign In
GPX MCP Server

GPX MCP Server

by gpxco
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

List devices

list_devices
Read-onlyIdempotent

Retrieve and filter account tracking devices by name, serial, status, or model to find a device ID; optionally include each device's last known position.

Instructions

List devices

Lists the account's tracking devices, filterable by name, serial, status and model. Use it to find a device id; include=last_position adds where each device is now. Each device's page in the GPX app is https://app.gpx.co/trackers/{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_devices"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameNoPartial match on the device name. Must not be greater than 255 characters.
pageNoPage number, starting at 1. Must be at least 1.
sortNoSort column, prefixed with - for descending.
modelNoA device model. Must not be greater than 255 characters.
serialNoExact match. A serial is looked up, not searched. Must not be greater than 255 characters.
statusNoA device lifecycle state.
includeNoInclude telemetry and/or last_position. Comma-separate values. Omitted by default because both are cross-store reads.
per_pageNoResults per page. Defaults to 50, capped at 100. Must be at least 1. Must not be greater than 100.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds a genuinely new detail, the deep-link URL template https://app.gpx.co/trackers/{id}, but says nothing about result volume, pagination behavior, or what the account scoping excludes — and the cross-store read caution for include is already in the schema.

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?

Three sentences, front-loaded with purpose, then the id-finding use case, then the link template. The leading repetition of the title ("List devices") before "Lists the account's..." is the only wasted line.

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 an eight-parameter read tool with no output schema and full schema coverage, the description supplies purpose, filter scope, the id use case, and a link-building affordance. Pagination defaults are left entirely to the schema, which is acceptable given its explicit per_page documentation.

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 all eight parameters including sort, page, and per_page are already documented at the field level. The description restates the filter set (name, serial, status, model) and one include value without adding matching semantics or format hints beyond the schema.

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 ("Lists the account's tracking devices") plus the filterable dimensions, which clearly separates it from the singular get_device sibling implied by "find a device id." It never names a sibling explicitly, so it lands just short of the top band.

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?

"Use it to find a device id" states the concrete task this tool serves, and the note about include=last_position clarifies an optional mode. There is no explicit when-not guidance or named alternative (e.g., get_device for a known id, list_device_positions for position history).

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