unofficialzaptecMCP

Get charger status

zaptec_get_status

Read-only

Read a Zaptec charger's current status: operating mode, charging power, session energy, per-phase current and voltage, cable, diagnostics, and available installation current.

Instructions

Current snapshot of the Zaptec charger: operating mode (disconnected / connected_requesting / connected_charging / connected_finished), charging power, session energy, per-phase current and voltage, cable, diagnostics, and the installation's available current. Read-only.

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

Input Schema

Name	Required	Description	Default
`charger_id`	No	Optional charger id. Defaults to ZAPTEC_DEFAULT_CHARGER_ID or the only charger.

Output Schema

Name	Required	Description	Default
`charger`	Yes
`charging`	Yes
`diagnostics`	Yes
`observed_at`	No
`installation`	Yes
`operating_mode`	Yes
`authorization_required`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 27, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's closing 'Read-only.' merely restates structured data. It adds no behavioral detail such as polling/rate limits, freshness guarantees, or whether unavailable chargers return errors, so with annotations carrying the safety profile this is a minimum-viable 3.

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?

A single front-loaded sentence opening with 'Current snapshot of the Zaptec charger' followed by a field list and a two-word safety tag. Efficient and scannable, though the field enumeration partially duplicates what the output schema already provides.

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?

An output schema exists, so return values need no explanation, and the annotations cover the read-only/open-world profile. The description still tells the agent the shape of the snapshot and the tool's defaulting behavior is in the schema, leaving nothing essential missing for correct invocation.

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 charger_id is fully documented (defaults to ZAPTEC_DEFAULT_CHARGER_ID or the only charger). The description adds no additional meaning about the parameter or about behavior when multiple chargers exist, so the baseline 3 applies.

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 resource (a Zaptec charger) and enumerates exactly what the snapshot contains: operating mode, charging power, session energy, per-phase current/voltage, cable, diagnostics, and available current. The word 'Current snapshot' cleanly separates it from zaptec_get_charge_history, so an agent can pick it without opening a schema.

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

Usage Guidelines3/5

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

Usage is only implied: 'Current snapshot' suggests this is the live-state tool versus the history and installation tools, but the description never says when to use it, when not to, or names an alternative. No prerequisites or defaulting behavior are discussed beyond the schema.

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

Deploy Server