Skip to main content
Glama
Sign In
GPX MCP Server

GPX MCP Server

by gpxco
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Show a place type

get_place_type
Read-onlyIdempotent

Retrieve a standard or custom place type by its slug to identify how a location is categorized before using or validating it.

Instructions

Show a place type

Returns one place type, standard or custom.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "placeTypeSlug": "<placeTypeSlug>"
    },
    "name": "get_place_type"
  }
}

Input Schema

NameRequiredDescriptionDefault
placeTypeSlugYesA place type slug, from `list_place_types`. Standard types can be read but not changed or deleted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

C2.9/5.0
Behavior2/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the mild nuance that results may be standard or custom types, and says nothing about failure behavior for an invalid slug or what a returned record looks like.

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 short lines with no padding, and the core purpose is front-loaded. The header line largely duplicates the title, but the body sentence carries the only substantive content, so there is very little waste.

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

Completeness3/5

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

For a one-parameter read tool with complete schema coverage and full annotations, most of what an agent needs is already in structured fields. However, there is no output schema, and the description does not sketch the returned record's shape or the error case, leaving a modest gap.

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%, and the schema itself explains the slug comes from `list_place_types` and that standard types are read-only. The description adds nothing beyond that, so the baseline 3 applies.

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-plus-resource ("Show a place type") and the second line clarifies the cardinality: "Returns one place type, standard or custom." That singular framing implicitly separates it from the sibling `list_place_types`, but the sibling is never named, so the differentiation is left for the agent to infer.

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

Usage Guidelines2/5

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

There is no explicit when-to-use guidance, no condition for choosing this over `list_place_types`, and no note about prerequisites or what happens when a slug is unknown. The only routing hint ("from `list_place_types`") lives in the schema's parameter description, not in the tool description itself.

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