Kia Access MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.6.1
Disambiguation5/5
Each tool has a clearly distinct purpose, with descriptive names and explanations that prevent confusion. Paired tools like start/stop are differentiated by action, and session management tools are well-separated.
Naming Consistency5/5
All tools follow the pattern `kia_verb_noun` in snake_case, providing a predictable and consistent naming structure across the entire set.
Tool Count5/5
16 tools cover the necessary operations for Kia vehicle access, including authentication, vehicle info, climate control, and charging. The count is appropriate for the domain without being overwhelming.
Completeness4/5
Core functionalities are well-covered, including login flow, vehicle status, location, climate, and charging control. Missing is door lock/unlock, but the primary use cases (EV climate and charging) are fully addressed.
Average 4.7/5 across 16 of 16 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 10 of 10 community issues answered or closed in the last 6 months
- 34 commits in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the passcode expires in ~2 minutes and reports expiresAt, and that it has no confirm gate. Annotations already indicate non-readOnly; description adds useful context without contradiction.
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 brief sentences covering purpose, dependency, channel guidance, and expiry. No wasted words, front-loaded with core purpose.
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?
Adequately covers prerequisite, channel selection, and expiry. Lacks explicit description of response format (e.g., success/expiresAt), but sufficient for a simple send tool with no output schema.
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%. Description adds context on where otpKey and xid come from (kia_start_login) and that notifyType should be determined by asking the user, which goes beyond schema descriptions.
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?
Clearly states it's Step 2 of MFA bootstrap, delivers a one-time passcode via SMS or email. Distinguishes from siblings by specifying dependency on kia_start_login and its place in the flow.
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?
Explicitly says it requires otpKey and xid from kia_start_login, advises asking user for channel, and notes expiration. Does not explicitly state when not to use it, but provides clear context on prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint: false, idempotentHint: true), the description reveals critical behavioral traits: the write is verified by re-reading evc/gts and comparing, the tool makes NO network call without confirm:true, and omitting a plug type drops that target. These details are not inferable from annotations or schema and are essential for safe use.
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?
The description is concise and information-dense, with four sentences that each convey a distinct critical fact: purpose, verification, replacement semantics, and dry-run behavior. It is front-loaded with the core action and avoids repetition or filler.
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?
Given the rich schema and annotations, the description covers the essential context: how targets are replaced, the verification readback, and the dry-run mode. It does not explicitly mention authentication prerequisites, but that is implicitly handled by the sibling login tools and the schema's reference to vehicleKey from the vehicle-list tool, so it remains adequately complete for an agent to call the tool correctly.
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?
The input schema already covers all parameters with detailed descriptions (100% coverage), including the meaning of confirm, verify, and the replacement behavior of targets. The description reinforces key points like 'Send BOTH plug types' and 'dry-run preview', but adds little new semantic information beyond what the schema already provides.
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 clearly states the tool's action: 'Set the target state of charge per plug type', which is specific and distinguishes it from read-only tools like kia_charge_targets. It also names the underlying API resource (`evc/sts`), leaving no ambiguity about what is being set.
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?
The description provides clear operational guidance: 'Send BOTH plug types — the list replaces the stored one' and explains the safety behavior of dry-run without confirm:true. It doesn't explicitly name alternative tools, but the write vs. read distinction is implied by the action verb and sibling tool names, so usage context is mostly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint, idempotentHint), the description discloses that the data is cached, not live, and that the return format depends on presence of coordinates. This adds significant behavioral context.
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?
The description is three sentences, all essential, with the main purpose front-loaded. No superfluous information.
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?
Given no output schema, the description explains both possible return forms (with/without coordinates) adequately. It covers key behavioral nuances, though it could briefly note that the block structure is from cmm/gvi read.
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% with a single parameter (vehicle_key) already described in the schema. The description adds no additional parameter meaning beyond what the schema provides, so a baseline score of 3 is appropriate.
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 clearly states the tool returns the vehicle's last known location from cached data, distinguishing it from a live GPS fix and referencing kia_refresh_status for a recent update. It also explains the conditional derivation of latitude/longitude and map link.
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?
The description explicitly advises to run kia_refresh_status first for a recent location, implying this tool is for cached data. While it doesn't list all alternative tools, the guidance is clear for the key decision point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), the description discloses that the tool reads the 'evc/gts' endpoint, returns one entry per plug type, and is verified live. It reinforces the read-only nature, providing full transparency for safe usage.
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?
The description is two concise sentences with no filler. It front-loads the core action and adds essential details (endpoint reference, per-plug-type output, verification, read-only nature) efficiently.
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 simple read-only tool with one parameter and no output schema, the description adequately explains the return structure (entries for AC and DC) and confirms live verification. It covers everything an agent needs to invoke the tool correctly.
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 covers the single parameter (vinKey) fully, so baseline is 3. The tool description does not add any additional meaning about the parameter, but also does not contradict or degrade the schema information.
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 clearly states the tool reads EV charge targets, specifying the verb 'Read' and the resource 'EV charge targets'. It further explains scope: per plug type (AC and DC), distinguishing it from sibling write tools like kia_set_charge_limits.
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?
The description implicitly guides usage by stating it is read-only, which contrasts with sibling tools that modify. However, it lacks explicit direction like 'use when you need to view charge targets, not to modify them'. The read-only hint and context from siblings make the purpose clear, but explicit alternatives would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, and idempotent hints. The description adds useful context like VIN masking and the list of returned fields, which goes beyond the annotations.
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?
Two concise sentences that front-load the purpose and key outputs, with no unnecessary words or redundancy.
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?
Given zero parameters and no output schema, the description fully explains the tool's behavior, including what fields are returned and the VIN masking policy.
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?
With zero parameters, the baseline is 4. The description adequately explains that no input is needed, and schema coverage is 100%, so no further param info is required.
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 clearly states 'List the vehicles enrolled on this Kia Owners account' with a specific verb and resource, and distinguishes itself from sibling tools by highlighting that it returns the vehicleKey needed by other tools.
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?
The description implies that this tool is a prerequisite because it returns 'the id every other Kia tool takes,' but it does not explicitly state when to use versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals that the remember-me token is stored locally and not returned, sessions refresh silently, and MFA becomes permanent – all beyond the annotations. No contradiction with annotations.
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?
Two sentences: first gives purpose, second explains behavior and effect. No wasted words, efficiently communicates critical 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?
Given the tool is part of a multi-step MFA process, the description covers prerequisites, effect on state, and future behavior. No output schema needed as the description explains return value (none). Fully complete.
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% with good descriptions. The tool description adds context about sourcing otpKey and xid from kia_start_login but does not significantly supplement the schema. Baseline 3 is appropriate.
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 clearly states this is 'Step 3 of the Kia MFA bootstrap' with the verb 'exchange' and resources 'passcode' and 'session'. It distinguishes from sibling tools by indicating its position in a sequence and referencing kia_start_login.
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?
The description says the resulting token is stored locally and MFA is never needed again, implying when to use it (after login, before other tools). It does not explicitly state when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the two-phase execution (preview vs actual), polling mechanism for airCtrl, separation of commandAccepted and stateConfirmed, and observed delay. Adds substantial context beyond annotations.
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?
Concise at ~80 words, front-loaded with purpose. Somewhat dense with technical details but no wasted sentences.
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?
Covers all parameters, return fields (commandAccepted, stateConfirmed, ign3), polling logic, and timing. Adequate given no output schema.
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%, but description adds practical context: vinKey is vehicleKey, confirm must be true, waitSeconds default/max/observed. Extra value beyond 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?
Clearly states 'Stop remote climate control' with specific endpoint and live-verified status. Unambiguous verb-resource pairing and distinguishable from sibling 'kia_start_climate'.
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?
Explains the critical confirm:true requirement and the dry-run behavior without it. Includes observed timings but lacks explicit when-to-use guidance versus alternatives beyond start/stop.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses critical behavioral traits: wakes the telematics unit, slower and draws power, only acknowledges request without returning data, and no completion signal. Annotations provide readOnlyHint and idempotentHint, but description adds nuance about side effects.
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?
Two sentences, no wasted words. Front-loaded with purpose, then behavioral details and usage guidance. Highly concise and well-structured.
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?
Given the tool's complexity (1 optional param, no output schema, but side effects and reliance on another tool), the description covers all necessary context: purpose, cost, workaround, and follow-up action.
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 already describes the optional vehicle_key with defaults. Description adds no extra parameter information beyond what the schema provides, so baseline score of 3 is appropriate.
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?
Clearly states it asks for a fresh reading from the car, distinguishing it from the cached kia_vehicle_status tool. The verb 'refresh' and resource 'status' are specific.
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 says to prefer the cached read unless staleness matters, highlights slower speed and power draw, and advises reading kia_vehicle_status afterwards to see refreshed values. Also mentions it only acknowledges the request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, idempotentHint), the description adds that the tool makes no network call, returns no secret, masks sensitive data (email, device id), and never includes session id or remember-me token. This fully discloses behavior without contradiction.
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?
The description is two sentences, front-loaded with purpose, then security details. Every word is valuable, no redundancy. Highly concise and well-structured.
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?
Given zero parameters and no output schema, the description fully covers the tool's purpose, behavior, security posture, and usage context. No gaps remain.
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?
With zero parameters and 100% schema coverage, the description does not need to add parameter info. It focuses on the output behavior, which is appropriate. Baseline 4 for zero parameters.
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 clearly states the tool checks server configuration and login status for Kia, including credentials, MFA bootstrap, and registered commands. It distinguishes itself by noting it makes no network call and returns no secret, setting it apart from siblings.
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?
The description explicitly says 'Start here when a Kia tool reports it is not configured,' providing clear guidance on when to use this tool. It does not explicitly mention when not to use it, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes far beyond annotations, disclosing the nested `climate.airCtrl` field, EV-specific `engine`/`ign3` behavior, separation of `commandAccepted` vs `stateConfirmed`, observed 30–60s delay, and the unconfirmed temperature behavior. It also reveals that seat/steering heating is deliberately not sent. This is rich, high-value behavioral context.
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?
The description is long but every sentence earns its place: it front-loads the core purpose, then packs essential caveats (dry-run, nested fields, EV behavior, timing, temperature unreliability, omitted heating) without redundancy. The structure is logical and information-dense.
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?
Given the tool's complexity (6 params, nested response semantics, no output schema), the description is remarkably complete. It explains success criteria (`climate.airCtrl` true), distinguishes request acceptance from state confirmation, warns about timing, and documents the lack of temperature/certain accessory support. This covers the likely failure modes and user expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds crucial semantics beyond property descriptions: it explains `confirm`'s dry-run vs real execution, `temperature` is best-effort and may be overridden by the car, `waitSeconds` reflects observed timing, and `durationMinutes` controls ignition duration. This meaningfully improves parameter understanding.
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 opens with a specific verb and resource: 'Start remote climate control / preconditioning (Kia `rems/start`, live-verified).' This clearly states what the tool does and distinguishes it from sibling tools like kia_stop_climate by naming the API operation.
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?
The description explains the critical usage distinction between dry-run (without confirm:true) and actual execution (with confirm:true), and warns about temperature best-effort and omitted seat heating. It does not explicitly name alternative tools for exclusion (e.g., 'use kia_stop_climate to stop'), but the context is clear and sufficient for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and idempotent hints, but the description adds substantial behavioral context: cached data semantics, the climate object's conditional presence via airTempRange/seatHeatCoolOption, the EV-specific ign3 field, syncDate advancing on every read, and unverified seat heat/vent encoding. This goes well beyond the annotations.
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?
The description is dense but every sentence conveys a critical caveat necessary for correct interpretation. It is front-loaded with the primary purpose and then systematically addresses freshness, climate presence, EV ignition, seat data encoding, and the meaning of absent seat blocks. Slightly long but disciplined.
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?
There is no output schema, yet the description fully compensates by explaining the most important return-value pitfalls: cached vs fresh, climate object presence, ign3 vs engine, syncDate semantics, raw seat heat/vent codes being unverified, and the meaning of absent seat data. This is comprehensive for a complex telematics tool.
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?
With 100% schema coverage, the baseline is 3. The description adds value by explaining include_raw returns the untrimmed status block (battery/EV detail, doors, tyres) and by detailing the internal request behavior that controls whether the nested climate object appears. The vehicle_key parameter is already well described in 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?
The description clearly states it reads the vehicle's cached status (cmm/gvi) and lists the specific data areas: door lock, ignition, and remote-climate block. It differentiates itself from the sibling kia_refresh_status by positioning itself as the fast, cached alternative.
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 advises using kia_refresh_status first when freshness matters, giving a concrete alternative. It also clarifies when to use include_raw and warns against interpreting seat-heat codes, providing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behavioral traits beyond the annotations: it returns a plaintext credential, bypasses MFA, grants full vehicle control, and requires confirm:true to even read the token. It also warns against displaying or logging the value. This far exceeds the annotation signals and thoroughly clarifies the security implications.
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?
Despite its length, every sentence serves a purpose: action, security warning, use case, exclusion, and behavior without confirmation. It is front-loaded with the core purpose and avoids fluff, maintaining high information density without redundancy.
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 credential-export tool with no output schema, the description fully covers purpose, use case, security impact, exclusion, and confirmation requirement. The absence of output schema is compensated by the thorough behavioral description, making the tool's behavior predictable and safe.
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?
The schema already documents the single confirm parameter with a clear description, so baseline is 3. The tool description adds value by explaining the consequence of omitting confirm:true ('the token is not even read') and the preview behavior, reinforcing and extending the schema. This extra context warrants a 4.
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 states the specific action ('Return the stored Kia remember-me token (rmtoken) IN PLAINTEXT') and clearly distinguishes it from sibling tools by explicitly forbidding its use for session checks and directing to kia_session_status. The verb+resource is highly specific and unambiguous.
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?
Provides explicit when-to-use context: 'moving a locally-bootstrapped session into a hosted deployment'. It also gives a clear when-not-to-use directive with an alternative tool named: 'Do NOT call it to "check the session" (use kia_session_status)'. This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool makes no network call and only forgets locally, beyond the idempotentHint annotation. It also explains the preview behavior without confirm:true.
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?
The description is concise, containing only essential information in a clear structure. It covers purpose, use cases, behavior, and parameter effect without extraneous content.
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?
Given the tool's simplicity (one optional boolean parameter, no output schema), the description is fully complete. It covers all necessary context: local action, no network call, recovery use case, and confirm behavior.
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?
The single parameter 'confirm' is well-described in the schema, but the description adds important context about its effect: without it, nothing is deleted and a preview is returned. This adds value beyond 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?
The description clearly states the tool discards the locally stored Kia session to force re-authentication. It distinguishes from sibling tools like kia_session_status and kia_start_login by specifying it is for forgetting the session.
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?
The description explicitly states when to use it: as a recovery path when the stored token no longer works due to revocation, password change, or device move. It also notes the only alternative is manual file deletion, providing clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations, it reveals that without confirm:true it's a dry-run preview, describes timing (~30-60s for batteryCharge to go true), and clarifies that the tool accepts requests even when not plugged in but no action occurs.
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?
Four sentences each adding distinct value: action, verification, prerequisite, and dry-run behavior. No filler, well-organized.
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?
Covers prerequisites, behavior, verification method, and confirmation nuance. Without an output schema, it provides enough info on expected state changes and how to confirm success.
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 already covers all three parameters with descriptions (100% coverage). The description adds context about the confirm flag's behavior and chargeRatio's default, but schema is already strong.
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 'start charging' with specific verb and resource, mentions underlying API endpoint, and clearly differentiates from siblings like kia_stop_charge or kia_set_charge_limits.
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 states that the car must be plugged in, warns that an unplugged car accepts the request but does nothing, recommends confirming with kia_vehicle_status, and explains the confirm:true parameter's role in making a network call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that without confirm:true no network call is made, that failed logins count and can cause permanent reCAPTCHA lockout, and that credentials must be pre-configured. Annotations only provide readOnlyHint and idempotentHint, which are insufficient; description fills the gap.
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?
Five sentences, each adding unique value: purpose, precondition, dry-run behavior, warning, and required state. No redundancy. Front-loaded with the most critical 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?
Given the complexity (MFA bootstrap, permanent lockout) and lack of output schema, the description covers purpose, preconditions, dry-run mode, return values (otpKey, xid), and critical warnings. Adequately prepares the agent for safe invocation.
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?
Only parameter 'confirm' is well-described in schema (must be true to proceed). Description adds context about dry-run preview and network call behavior, reinforcing the schema. Schema coverage is 100%, so baseline 3; description adds meaningful usage context.
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?
Clearly states it's Step 1 of a one-time MFA bootstrap, identifies the verb ('start login') and resource ('Kia MFA bootstrap'), and distinguishes from sibling tools like kia_send_otp and kia_verify_otp.
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 specifies preconditions: only needed when kia_session_status shows hasSession:false. Explains dry-run behavior with confirm:false and warns against repeated failures due to permanent lockout risk.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the effect (batteryCharge going false) takes 30-60s, warns not to trust success status, and explains dry-run behavior. Goes well beyond annotations which only indicate idempotent and non-read-only.
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 concise sentences, each adding critical information. No redundancy or waste.
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?
Covers usage, behavior, return expectations, and verification. Even without an output schema, the description fully prepares the agent for invocation and follow-up.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
For `vinKey`, notes it is not the VIN; for `confirm`, explains its role in enabling vs previewing the call. This adds value beyond the schema descriptions.
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 clearly states 'stop charging' and specifies the API endpoint `evc/cancel`. This distinguishes it from sibling tools like `kia_start_charge`.
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?
Provides explicit guidance: confirm with `kia_vehicle_status` to verify effect, and explains that `confirm:true` is required for actual execution; without it, a dry-run preview is returned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![kiaaccess-mcp MCP server](https://glama.ai/mcp/servers/chrischall/kiaaccess-mcp/badges/card.svg)](https://glama.ai/mcp/servers/chrischall/kiaaccess-mcp)

Score Badge

Copy to your README.md:

[![kiaaccess-mcp MCP server](https://glama.ai/mcp/servers/chrischall/kiaaccess-mcp/badges/score.svg)](https://glama.ai/mcp/servers/chrischall/kiaaccess-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/chrischall/kiaaccess-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server