Skip to main content
Glama

kia_refresh_status

Read-onlyIdempotent

Ask the car for a fresh status reading. Because Kia only acknowledges the request, retrieve updated data by checking vehicle status afterward.

Instructions

Ask the car for a fresh reading (rems/rvs, requestType 0). This WAKES THE TELEMATICS UNIT, so it is much slower than kia_vehicle_status and draws a little power — prefer the cached read unless staleness matters. Kia only acknowledges the request; it does not return the new data and gives no completion signal, so read kia_vehicle_status afterwards to see the refreshed values.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
vehicle_keyNovehicleKey from kia_list_vehicles. Optional: defaults to the only vehicle when the account has exactly one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
  2. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

Beyond annotations, it discloses that the call wakes the telematics unit, is slower, draws power, and that Kia only acknowledges the request without returning data or a completion signal. This paints a clear behavioral model beyond readOnly/idempotent hints and does not contradict them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three dense sentences front-load the purpose, then cover latency/power trade-off, usage preference, and asynchronous behavior. Every sentence earns its place with no filler.

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?

The described async/no-return behavior compensates for the missing output schema, and the follow-up instruction to read kia_vehicle_status completes the workflow. With one optional, well-documented parameter, nothing critical 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 coverage is 100% and the sole parameter is already fully documented with type, source, and default behavior. The description does not add parameter-specific meaning, but none is needed.

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 names the action ('Ask the car for a fresh reading'), the target resource (rems/rvs, requestType 0), and distinguishes it from kia_vehicle_status. It is immediately clear this is a refresh trigger versus the cached read.

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?

Explicitly contrasts with kia_vehicle_status, states when to prefer the cached read ('unless staleness matters'), and instructs to call kia_vehicle_status afterwards to observe results. This is unambiguous guidance on when and how to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.