Skip to main content
Glama
Sign In
here-hgv-mcp

here-hgv-mcp

by craigst
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

HERE API health and entitlement probe

here_api_health
Read-only

Probes the configured HERE API key across all used services and reports connectivity, status, latency, and rate-limit headers, distinguishing bad keys, missing entitlements, outages, and network faults.

Instructions

Probe the configured HERE API key against every service this server uses and report connectivity, HTTP status, latency and any rate-limit headers. Services probed: geocode, reverseGeocode, discover, autosuggest, routing, matrix, isoline, traffic, mapImage; waypointSequence only when probeCalculations=true (it has no /health endpoint and would consume routing quota). Use this first when a HERE tool fails: it distinguishes a bad/expired key (401/403), a missing entitlement (403), an outage (5xx) and a network problem, service by service. Note: HERE does not expose remaining monthly quota per key through these APIs; x-ratelimit-* headers are reported when present. HERE_API_KEY values are never returned — only whether one is configured.

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": "here_api_health"
  }
}

Input Schema

NameRequiredDescriptionDefault
servicesNoOptional subset of services to probe (default: all). e.g. ["routing","traffic"].
timeoutMsNoPer-service timeout in milliseconds (default 8000).
probeCalculationsNoAlso probe waypointSequence with a real (tiny) calculation — consumes quota (default false).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well past the readOnlyHint/openWorldHint annotations: it discloses that waypointSequence is skipped by default because it lacks a /health endpoint and burns routing quota, that x-ratelimit-* headers are only reported when present, that remaining monthly quota is unavailable, and that the key value itself is never returned. These are exactly the side effects and limits an agent needs before calling.

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?

Front-loaded with purpose, then service list, then the failure-diagnosis use case, then caveats — a logical order with no filler. It is dense and long for one paragraph, but each clause (quota caveat, header caveat, key-redaction note) carries distinct information.

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?

With no output schema, the description carries the burden of describing returns and does so: connectivity, HTTP status, latency and rate-limit headers per service. Combined with the enumerated service set and caveats, an agent has everything needed to invoke and interpret this probe.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds rationale the schema lacks — notably why probeCalculations gates waypointSequence and what quota cost that incurs, plus the default full-service list behind the services array. It reinforces rather than merely repeats the schema.

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?

States a specific verb and object — probe the configured HERE API key against every service the server uses — and enumerates exactly which services are covered. The diagnostic role is clearly distinct from the sibling tools (here_geocode, here_route, etc.), which call services rather than test them.

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 this first when a HERE tool fails" gives an explicit trigger condition, and the description maps error classes (401/403, 403 entitlement, 5xx, network) to diagnoses. There is no explicit when-not-to-use statement, but the diagnostic framing makes the boundary with the real service tools clear.

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