What can you do with this server?

The Anker Solix MCP Server connects an MCP host (e.g., Claude Desktop, Claude Code) to your Anker Solix solar setup via an unofficial cloud API. All tools are read-only — no settings are changed. Site & Device Discovery * list_sites — List all Anker power systems (sites) on your account * get_site_overview — Get power-flow summary for a site (solar input, battery charge/discharge, home load, grid import/export) * list_devices — List every device (Solarbanks, expansion packs, Smartmeters, etc.) keyed by serial number * get_device — Get the full cached detail record for a specific device by serial number Solarbank & Battery * list_solarbanks — List devices identified as Solarbanks or expansion battery packs * get_solarbank_status — Get current battery state of charge, solar input/output power, charge/discharge power, and temperature * get_solarbank_schedule — Get the configured charge/discharge schedule and output-power plan Smartmeter * list_smartmeters — List devices identified as Anker Smartmeters * get_smartmeter_status — Get current grid import/export power and other reported fields Energy Statistics * get_energy_statistics — Fetch live (non-cached) energy totals: solar production, battery charge/discharge, grid import/export, and home usage across all sites/devices, with time-series breakdowns for day/week/month/year Maintenance & Account * refresh_data — Force an immediate refresh of all cached data, bypassing the normal throttle * get_account_info — Get basic authenticated account info (nickname, identifiers) with credentials redacted The server supports both stdio (subprocess) and streamable-HTTP (remote) transports with bearer-token authentication.

How do I use anker-solix-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@anker-solix-mcp what is my current solar power production?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

anker-solix-mcp

by gkoenig

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Anker Solix MCP Server

Security Ruff Python 3.12+ License: MIT

An MCP (Model Context Protocol) server that exposes data from an Anker Solix solar setup — Solarbank, expansion battery packs, and Smartmeter — as tools an LLM agent (Claude Desktop, Claude Code, or any other MCP host) can call directly. Ask things like "how much solar power are we producing right now?" or "what's the battery state of charge?" and have the assistant fetch live numbers instead of you opening the Anker app.

Built against and tested with a Solarbank 2 E1600 Pro + 1600 expansion battery pack + Anker Smartmeter, but the tools are written generically enough to work with any Solix devices linked to your Anker account.

⚠️ Unofficial. This project talks to Anker's cloud API via the reverse-engineered, community-maintained anker-solix-api library (the same one behind the Home Assistant Anker Solix integration). It is not affiliated with or endorsed by Anker Innovations, and Anker can change their API at any time and break this.

Related MCP server: fronius-mcp

How this fits together

MCP (Model Context Protocol) is a small, open protocol for connecting an LLM application ("host", e.g. Claude Desktop or Claude Code) to external tools and data. The pieces:

MCP host — the chat application (Claude Desktop, Claude Code, etc). It reads the model's requests to call a tool, invokes the tool, and feeds the result back into the conversation.
MCP server — this project. A small program that declares a set of tools (name, description, input schema, and an implementation) and speaks the MCP protocol over a transport.
Transport — how the host and server talk. This server supports two:
- stdio (the default) — the host launches it as a subprocess and exchanges JSON-RPC messages over its stdin/stdout. No network port, no auth handshake, the host manages the process lifecycle. This is what you want for Claude Desktop/Claude Code on the same machine (see Connecting to an MCP client).
- streamable-http — the server instead listens on a TCP port and speaks MCP over HTTP (with SSE for streaming responses), so it can run as a long-lived, independently-deployed service that one or more remote MCP hosts connect to (see Running over HTTP).

┌─────────────────┐   JSON-RPC over stdio   ┌───────────────────────┐   HTTPS   ┌──────────────┐
│  MCP host        │ ─────────────────────▶ │  anker-solix-mcp       │ ────────▶ │ Anker cloud   │
│ (Claude Desktop,  │ ◀───────────────────── │  (this server, a       │ ◀──────── │ API           │
│  Claude Code, …)  │   tool calls/results    │  subprocess)           │  data     │ (unofficial)  │
└─────────────────┘                         └───────────────────────┘           └──────────────┘

Within the server, each tool is just a Python async function decorated with @mcp.tool(). The official Python MCP SDK's FastMCP class turns the function's type hints and docstring into the JSON schema and description the model sees — you write plain Python, the protocol plumbing (schema generation, JSON-RPC framing, transport) is handled for you.

Repository structure

anker-solix-mcp/
├── pyproject.toml            # package metadata, dependencies, console-script entry point
├── uv.lock                    # locked, reproducible dependency versions (uv-managed, committed)
├── .python-version             # pins the interpreter uv uses/installs for this project (3.12)
├── .env.example               # template for Anker account credentials
├── .github/
│   ├── workflows/
│   │   ├── ci.yml              # lint (ruff) + type check (pyright) + test (pytest), every push
│   │   └── security.yml        # pip-audit (dependency CVEs) + CodeQL, every push + weekly
│   └── dependabot.yml         # weekly version-update PRs (Python deps + GitHub Actions)
├── src/
│   └── anker_solix_mcp/
│       ├── server.py          # builds the FastMCP app, registers tool modules, runs stdio or HTTP transport
│       ├── _dev.py            # module-level `mcp` object for `uv run mcp dev` (MCP Inspector) only
│       ├── config.py          # loads Settings (credentials, refresh interval, transport) from the environment
│       ├── client.py          # AnkerSolixClient: lazy auth + refresh-throttled wrapper around AnkerSolixApi
│       ├── http_auth.py       # BearerTokenMiddleware: static-token gate for the HTTP transports
│       ├── util.py            # sanitize() (credential redaction), filter_devices() (heuristic type filter)
│       └── tools/
│           ├── sites.py       # list_sites, get_site_overview
│           ├── devices.py     # list_devices, get_device
│           ├── solarbank.py   # list_solarbanks, get_solarbank_status, get_solarbank_schedule
│           ├── smartmeter.py  # list_smartmeters, get_smartmeter_status
│           ├── energy.py      # get_energy_statistics, get_energy_analysis
│           └── maintenance.py # refresh_data, get_account_info
└── tests/
    ├── test_util.py           # redaction / filtering unit tests
    ├── test_http_auth.py      # BearerTokenMiddleware accept/reject cases
    └── test_server.py         # smoke-tests the assembled server against a fake client (no network)

Each tools/*.py module exposes one register(mcp, client) -> None function that attaches its tools to the shared FastMCP instance, closing over a shared AnkerSolixClient. server.py is just the assembly point — this keeps each domain's tools in one place and makes it easy to add a new file for a new domain (see Extending).

Prerequisites

uv — used for everything (dependency management, virtualenv creation, running the server and tests). Install it with curl -LsSf https://astral.sh/uv/install.sh | sh or see the uv install docs.
An Anker account with at least one Solix system registered in the Anker app.
Nothing else — you don't need Python preinstalled. This project pins Python 3.12 (required by the upstream anker-solix-api library) via .python-version/requires-python, and uv will transparently download that exact interpreter the first time you run a uv command here if it's not already on your machine.

Installation

git clone <this-repo-url> anker-solix-mcp
cd anker-solix-mcp
uv sync

uv sync reads pyproject.toml + the committed uv.lock, downloads Python 3.12 if needed, creates a project-local .venv/, and installs every dependency (including the dev-only ones like pytest, from the dev dependency group) at the exact locked versions. Nothing needs activating — every command below is run through uv run ..., which transparently uses that .venv.

anker-solix-api isn't published on PyPI, so it's pulled straight from its GitHub repo (see the anker-solix-api @ git+https://... entry in pyproject.toml, pinned to a commit in uv.lock) — uv supports Git dependencies natively, no extra configuration needed.

If you ever change a dependency in pyproject.toml by hand, run uv lock to update uv.lock to match (or use uv add <package> / uv remove <package>, which update both files for you in one step).

Configuration

Copy the example env file and fill in your Anker account credentials (the same ones you use to log into the Anker mobile app):

cp .env.example .env
$EDITOR .env

Variable	Required	Description
`ANKER_EMAIL`	yes	Anker account email
`ANKER_PASSWORD`	yes	Anker account password
`ANKER_COUNTRY`	no	Two-letter country code used at signup (default `DE`)
`ANKER_REFRESH_SECONDS`	no	Minimum seconds between automatic data refreshes (default `60`)
`ANKER_SITE_ID`	no	Default site ID, if you have more than one Anker Solix system
`ANKER_MCP_TRANSPORT`	no	`stdio` (default), `streamable-http`, or `sse`. See Running over HTTP
`ANKER_MCP_HOST`	no	Bind address for HTTP transports (default `127.0.0.1`)
`ANKER_MCP_PORT`	no	Bind port for HTTP transports (default `8000`)
`ANKER_MCP_PATH`	no	HTTP path the MCP endpoint is mounted at (default `/mcp`)
`ANKER_MCP_AUTH_TOKEN`	no	Bearer token required on every HTTP request. Strongly recommended for any HTTP transport not bound to `127.0.0.1`; see Running over HTTP

Credentials are only ever read from the environment/.env file and used to authenticate against Anker's own API — nothing is sent anywhere else. Tool outputs are also passed through a redaction step (see Design notes) so tokens/passwords can't leak into a conversation even if they show up in a raw API response.

Never commit your .env file. It's already listed in .gitignore.

Running the server standalone

Before wiring this into an MCP host, it's worth checking it actually talks to your account. The MCP Python SDK ships an inspector UI for exactly this:

uv run mcp dev src/anker_solix_mcp/_dev.py

This opens the MCP Inspector in your browser, where you can call each tool by hand and see the raw JSON it returns. It points at _dev.py rather than server.py because the mcp dev CLI needs a module-level FastMCP object to introspect, and server.py deliberately doesn't build one at import time (build_server() takes an explicit client; main() only constructs one after loading Settings) — that's what keeps importing server.py free of any credential/network requirement, e.g. for the test suite. _dev.py is the one place that trades that off for the Inspector's sake, so it still needs ANKER_EMAIL/ANKER_PASSWORD set.

Alternatively, just run the server directly (it will sit waiting for stdio input, which is expected):

uv run anker-solix-mcp

Connecting to an MCP client

Clone the repo to a local folder once, then point each MCP client at that checkout:

mkdir -p ~/src
cd ~/src
git clone https://github.com/gkoenig/anker-solix-mcp.git
cd anker-solix-mcp
uv sync

Claude Code

Use that local path in Claude Code's MCP settings:

claude mcp add anker-solix -- uv --directory ~/src/anker-solix-mcp run anker-solix-mcp

Or add it by hand to your Claude Code MCP settings:

{
  "mcpServers": {
    "anker-solix": {
      "command": "uv",
      "args": ["--directory", "~/src/anker-solix-mcp", "run", "anker-solix-mcp"]
    }
  }
}

Claude Desktop

Use the same local checkout in claude_desktop_config.json (Settings → Developer → Edit Config), then restart Claude Desktop.

Cline

Cline stores MCP servers in cline_mcp_settings.json, using the same mcpServers shape as the other clients here. Add the server entry there and replace the path with your local checkout:

{
  "mcpServers": {
    "anker-solix": {
      "command": "uv",
      "args": ["--directory", "~/src/anker-solix-mcp", "run", "anker-solix-mcp"]
    }
  }
}

Save the file, reload Cline, and ask it to call tools like "list my sites" or "show solarbank status".

Any other MCP host

Any host that can launch a local process and speak MCP-over-stdio can use this server — point it at uv run anker-solix-mcp (or the equivalent python -m anker_solix_mcp inside the project's virtualenv) with the working directory set to this repo (or ANKER_EMAIL/ANKER_PASSWORD/etc. exported directly in the host's environment instead of a .env file).

Running over HTTP

Everything above assumes stdio: the MCP host runs on the same machine and launches this server itself. If instead you want to run the server as a standalone, long-lived service — e.g. on a home server/NAS/Raspberry Pi near your network, with one or more MCP hosts (a laptop, a phone client, several people) connecting to it remotely — use the streamable-http transport instead.

Starting it

ANKER_MCP_TRANSPORT=streamable-http \
ANKER_MCP_HOST=127.0.0.1 \
ANKER_MCP_PORT=8000 \
ANKER_MCP_AUTH_TOKEN=$(openssl rand -hex 32) \
  uv run anker-solix-mcp

Or set the same variables in your .env file (see .env.example) — note ANKER_MCP_AUTH_TOKEN needs to be a fixed value there, not regenerated each run, since clients need to know it. The process now behaves like a normal web server: it stays running, logs to stderr, and listens on http://<host>:<port><path> (default path /mcp) until you stop it (Ctrl+C or SIGTERM — the Anker API session is closed cleanly on shutdown).

Point an HTTP-capable MCP client at that URL, passing the token as a bearer header, e.g. for Claude Code:

claude mcp add --transport http anker-solix http://127.0.0.1:8000/mcp \
  --header "Authorization: Bearer <the ANKER_MCP_AUTH_TOKEN value>"

or in a client's MCP settings JSON:

{
  "mcpServers": {
    "anker-solix": {
      "type": "http",
      "url": "http://127.0.0.1:8000/mcp",
      "headers": {
        "Authorization": "Bearer <the ANKER_MCP_AUTH_TOKEN value>"
      }
    }
  }
}

For Cline, this same file works: keep using mcpServers, but switch the entry to the HTTP shape above when you run the server with ANKER_MCP_TRANSPORT=streamable-http. For local stdio use, keep the Cline-specific entry from Connecting to an MCP client.

What changes vs. stdio, and what to consider

Moving from stdio to HTTP turns this from "a subprocess only the host that launched it can see" into "a network service" — several things that stdio gave you for free now become your responsibility:

Exposure / access control. Anyone who can reach the port can call every tool here — read-only, but that still means your Solix site/device data and Anker account info (see Available tools) are readable by whoever connects. Set ANKER_MCP_AUTH_TOKEN (see Configuration) to require a matching Authorization: Bearer <token> header on every request — anker_solix_mcp.http_auth.BearerTokenMiddleware rejects anything else with 401. This is a deliberately simple static-token check, not full OAuth: mcp[cli]'s FastMCP does support plugging in a real TokenVerifier/OAuth provider (FastMCP(auth=...)), but that requires standing up OAuth protected-resource metadata (an issuer_url, discovery endpoints, ...) — overkill for a single-account personal server. If you need that flow (e.g. multiple distinct users/identities, token expiry, scopes), swap in a real TokenVerifier instead of ANKER_MCP_AUTH_TOKEN. Without the token set, the server logs a startup warning and accepts unauthenticated requests — only acceptable on loopback or an already-trusted network (see below).
Recommended: keep it off the public internet. A bearer token guards the endpoint, but it's still sent as plain HTTP unless something adds TLS (see below) — layer on network-level protection too:
1. Loopback only (ANKER_MCP_HOST=127.0.0.1, the default) if the MCP host runs on the same machine — gets you nothing over stdio, so prefer stdio in that case.
2. Private network / VPN — bind to your LAN interface (or 0.0.0.0) but only reach it over a VPN you control (Tailscale, WireGuard) or your home LAN, never a port forwarded to the public internet.
3. Reverse proxy in front (Caddy, nginx, Traefik) if you do need access from outside your network: terminate TLS there (streamable-http has no TLS of its own) — keep ANKER_MCP_AUTH_TOKEN set either way, so the token and TLS cover different risks (who's allowed vs. is the traffic readable in transit).
Single process, not a fleet. AnkerSolixClient throttles refreshes and authenticates lazily using in-process state (an asyncio.Lock and a last-refresh timestamp — see client.py). That only works correctly within one process: don't run multiple uv run anker-solix-mcp instances or a multi-worker server (e.g. uvicorn --workers N) in front of the same Anker account, or the refresh throttle stops meaning anything and you risk hammering Anker's API from several unsynchronized processes at once. One process comfortably serves many concurrent MCP clients/sessions.
Keep it running. Unlike stdio (where the host starts/stops the process for you), you're now responsible for the process lifecycle: run it under a process supervisor — a systemd user/system service, a Docker container with restart: unless-stopped, tmux/screen for a quick manual setup — so it survives reboots and crashes and its logs (it logs to stderr) go somewhere you can check.
Credentials still come from the environment. Nothing changes here — ANKER_EMAIL/ANKER_PASSWORD/etc. are still read once at process start (from the environment or .env in the working directory). Make sure whatever supervises the process sets them the same way you would for stdio; there's no per-request credential handling to worry about since this is still a single-account tool, not a multi-tenant service.
sse transport is also available (ANKER_MCP_TRANSPORT=sse) for older MCP clients that predate streamable-http, but it's deprecated in the MCP spec — prefer streamable-http unless you specifically need it.

Available tools

Tool	Description
`list_sites`	List every Anker power system ("site") on the account, keyed by site ID.
`get_site_overview`	Full cached detail record for one site (power-flow summary, if reported).
`list_devices`	List every device (Solarbank, expansion pack, Smartmeter, …) keyed by serial number.
`get_device`	Full, unfiltered cached detail record for one device.
`list_solarbanks`	Devices that look like Solarbanks / expansion battery packs.
`get_solarbank_status`	Battery SoC, solar input, output power, charge/discharge power, temperature, etc.
`get_solarbank_schedule`	The configured charge/discharge schedule / output-power plan, if present.
`list_smartmeters`	Devices that look like Anker Smartmeters.
`get_smartmeter_status`	Current grid import/export power and other reported fields.
`get_energy_statistics`	Fresh (non-cached) energy totals: production, charge/discharge, grid import/export, home usage.
`get_energy_analysis`	Time-series energy breakdown for a site (day/week/month/year); `range_type="day"` returns intraday (~20-min) points for sub-daily queries like night-time usage.
`refresh_data`	Force an immediate refresh of all cached data, bypassing the throttle.
`get_account_info`	Basic Anker account info (nickname, etc.), credentials redacted.

All tools are read-only — none of them changes a device setting. That's a deliberate scope choice (see Design notes and Extending if you want to add control tools yourself).

Design notes

Why tools return mostly raw, pass-through data. anker-solix-api talks to an undocumented private API — its cached data's exact shape varies by device model and firmware, and can change without notice. Rather than hardcoding field names that might not match your specific setup (and silently dropping data that doesn't fit an assumed schema), most tools return the underlying library's cached dict close to as-is, scoped to the relevant site/device. Modern LLMs are good at reading arbitrary JSON and picking out the field the user asked about, so this trades a bit of "raw JSON in the transcript" for resilience against upstream schema drift. list_solarbanks / list_smartmeters apply a best-effort heuristic filter (matching known model codes / type strings) but fall back to returning everything if nothing matches, rather than silently returning an empty result.

Redaction. Every tool response is passed through util.sanitize(), which recursively redacts any dict key that looks like a credential (password, token, secret, cookie, auth_*, …) before it's returned. This is defense-in-depth on top of never printing credentials directly — the account cache in particular could plausibly carry session-related fields.

Refresh throttling. AnkerSolixClient.refresh() is throttled to ANKER_REFRESH_SECONDS (default 60s) so a burst of tool calls within one conversation turn costs a single round trip to Anker's API, not one per tool. get_energy_statistics, get_energy_analysis and refresh_data intentionally bypass the throttle, since "give me the latest number" is the most common reason to call them.

Lazy authentication. The Anker API client and its HTTP session are only created on first use (inside AnkerSolixClient._ensure_api), not at import time — so importing the server module, or running its test suite, never makes a network call or requires credentials to be present.

Development

uv sync            # dev dependency group (pytest, pytest-asyncio, ruff, pyright, pip-audit) is included by default
uv run pytest
uv run ruff check .          # lint
uv run ruff format .         # format (add --check to only verify, e.g. in CI)
uv run pyright               # type check

tests/test_server.py builds the MCP server against a small fake client (see FakeAnkerSolixClient), so the test suite runs with no Anker credentials and no network access. tools/*.py and build_server() take the client as AnkerSolixClientProtocol (see client.py) rather than the concrete AnkerSolixClient specifically so that duck-typed stand-in type-checks too.

To add or upgrade a dependency, prefer uv add <package> (or uv add --group dev <package> for a dev-only tool) over hand-editing pyproject.toml — it resolves and updates uv.lock for you in the same step. Run uv lock --upgrade occasionally to pick up new compatible versions, including a newer commit of anker-solix-api if the upstream library has moved on.

Continuous integration & security

Every push, on every branch, runs three GitHub Actions jobs (.github/workflows/ci.yml):

Job	Command
Lint	`uv run ruff check .` + `uv run ruff format --check .`
Type check	`uv run pyright`
Test	`uv run pytest`

Security scanning runs on every push plus a weekly schedule (.github/workflows/security.yml):

pip-audit — checks every resolved dependency version (from the locked environment) against known CVE databases.
CodeQL — GitHub's static analysis, scanning this project's own Python source for security-relevant bug patterns (separate from dependency CVEs).

.github/dependabot.yml additionally opens PRs for version updates on a weekly schedule, for both Python dependencies (uv ecosystem) and the GitHub Actions used in the workflows themselves. Note that anker-solix-api is a git dependency with no fixed tag, so Dependabot can version-bump every other dependency here but not that one specifically — re-run uv lock --upgrade periodically to pick up newer commits of it.

Extending

To add a new tool:

Add an async def function to an existing tools/*.py module (or create a new module for a new domain), decorated with @mcp.tool() inside that module's register(mcp, client) function.
Write a clear docstring — the MCP client (and, in turn, the model) sees it as the tool's description, so be explicit about what the tool returns and when to call it.
If it's a new module, register it in build_server() in server.py.
Add a test in tests/ using FakeAnkerSolixClient (extend it if your tool needs data the fake doesn't provide yet).

To add a device-control tool (e.g. changing the Solarbank's output power or charge schedule via AnkerSolixApi.set_station_parm / set_device_attributes), consider gating it behind explicit user confirmation in your MCP host, since unlike the read-only tools here, a mistaken call would actually change how your hardware behaves.

Available Tools

12 tools

get_account_infoA

Get basic info about the authenticated Anker account (e.g. nickname, account/email identifiers), with any credentials or tokens redacted.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It indicates redaction of credentials/tokens, which is helpful. However, it does not disclose authentication requirements, error cases, or read-only nature explicitly.

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?

A single sentence with examples. No unnecessary words. Perfectly front-loaded with the action and resource.

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?

For a tool with no parameters and an output schema, the description provides sufficient context about what is returned. It could mention authentication prerequisite, but overall complete.

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, schema coverage is 100%. The description correctly omits parameter details as none exist, meeting the baseline expectation for a parameterless tool.

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 verb 'Get' and the resource 'basic info about the authenticated Anker account', with specific examples like nickname and email identifiers. It distinguishes itself from sibling tools which focus on devices, sites, or energy data.

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 use for retrieving account-level information. Given the sibling context, it's clear when to use this tool over others. However, it lacks explicit guidance on when not to use it or direct mention of alternatives.

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

get_deviceA

Get the full cached detail record for one device by serial number, with no type-specific filtering applied.

    Args:
        device_sn: The device serial number, as returned by list_devices.

ParametersJSON Schema

Name	Required	Description	Default
`device_sn`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds that the record is 'cached,' which implies eventual consistency, and notes 'no type-specific filtering.' However, it does not explicitly state whether the operation is read-only or disclose other behaviors like rate limits or permission requirements, leaving gaps.

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 plus a structured Args block. The purpose is front-loaded, and every sentence adds value. No superfluous content.

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 tool's simplicity (one parameter, output schema present), the description covers the essentials: what is returned, how to obtain the serial number, and that no filtering is applied. It could be slightly more complete by noting the read-only nature, but overall it's adequate.

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 has one parameter (device_sn) with no description. The description adds meaningful context: 'The device serial number, as returned by list_devices,' guiding the agent on the value source. This compensates for the 0% schema coverage, though it could further specify format or constraints.

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 verb 'Get', the resource 'full cached detail record', and the method 'by serial number'. It also specifies 'no type-specific filtering applied', which distinguishes it from sibling tools that might filter by type. The purpose is unambiguous.

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 context by noting the serial number is 'as returned by list_devices', implying a workflow where list_devices should be used first. While it doesn't explicitly state when not to use the tool or provide alternatives, the guidance is clear enough for an agent to understand the prerequisite.

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

get_energy_statisticsA

Fetch fresh energy statistics from the Anker cloud API: solar production, battery charge/discharge, grid import/export, and home usage totals, for every site/device the account can see.

    Unlike the other tools, this always makes a live request rather than
    serving the throttled cache, since energy totals are the numbers most
    often asked about ("how much did we produce/use today").

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.1/5.0

Behavior3/5

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

With no annotations provided, the description must disclose all behavioral traits. It adds the important context that the tool makes a live request (not cached), which is a key behavioral difference from siblings. However, it does not mention potential rate limits, authentication requirements, failure behavior, or the impact of making a live request (e.g., higher latency). The description adequately conveys the fresh data aspect but lacks broader behavioral detail.

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 mostly concise, using two sentences plus a brief rationale. The first sentence clearly states the action and outputs. The second sentence adds behavioral context (live vs. cache) and reasoning. It could be slightly trimmed (e.g., remove 'the numbers most often asked about' which is implied by the context) but overall is efficient and well-structured.

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 tool has no parameters and an output schema exists (though not provided), the description explains the return values (solar production, battery, grid, home usage) and the caching behavior. It covers why this tool exists alongside siblings. For a zero-parameter tool, this is reasonably complete, though it could mention that the output covers all sites/devices the account can see.

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 input schema has 0 parameters and 100% schema description coverage (vacuously). The baseline for 0 parameters is 4. The description does not add parameter information because there are none, but it does explain what the tool returns, which indirectly clarifies that no input is needed. No improvement possible without inventing 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 specifies the verb 'Fetch', the resource 'energy statistics', and the scope 'for every site/device the account can see'. It lists the specific data types (solar production, battery, grid, home usage), making the purpose unambiguous. It distinguishes from siblings by highlighting the live request behavior.

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 states that this tool makes a live request instead of using a throttled cache, and that energy totals are the most often asked about data. This gives clear guidance on when to use it (for fresh energy totals) and implicitly contrasts with other cached tools. It lacks explicit exclusion criteria (e.g., when not to use) but is otherwise clear.

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

get_site_overviewA

Get the cached detail record for one site, including whatever current power-flow summary the Anker cloud API reports for it (e.g. solar input, battery charge/discharge, home load, grid import/export).

    Args:
        site_id: The site ID, as returned by list_sites.

ParametersJSON Schema

Name	Required	Description	Default
`site_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries the burden. It transparently notes the data is 'cached' and describes the power-flow summary contents. No contradictions or missing critical traits.

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 with two sentences plus an Args line. It is front-loaded with the main purpose, followed by examples and parameter hints, with no wasted words.

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?

The description adequately covers what the tool returns (cached record with power-flow summary). Given an output schema exists for return values, it is sufficiently complete. Sibling tools context is clear.

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 has 0% description coverage, but the description adds meaning by stating site_id is 'The site ID, as returned by list_sites.' This provides context beyond the schema's type and title.

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 retrieves a cached detail record for one site including power-flow summary, with specific examples like solar input, battery, etc. The name and description distinguish it from siblings like list_sites (list only) and get_device (specific device data).

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?

It implies usage by specifying site_id comes from list_sites, but no explicit guidance on when to use versus alternatives like get_energy_statistics. The context is limited to a single use case.

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

get_smartmeter_statusA

Get current status for one Smartmeter: grid import/export power and any other fields the Anker cloud API reports for this device.

    Args:
        device_sn: The Smartmeter's device serial number (see
            list_smartmeters or list_devices).

ParametersJSON Schema

Name	Required	Description	Default
`device_sn`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description carries full disclosure burden. It honestly states that the tool returns 'grid import/export power and any other fields the Anker cloud API reports,' indicating an open-ended output. However, it does not explicitly state read-only nature or potential side effects, though the verb 'Get' implies no mutation.

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: one sentence for purpose plus a parameter line. It is front-loaded with the main action and contains no fluff. Every part earns its place.

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 output schema exists, the description need not detail return values. It covers the tool's purpose and parameter sourcing. The mention of 'any other fields' is vague but truthful. No obvious gaps remain for a simple status retrieval 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?

Only one parameter (device_sn) with 0% schema coverage. The description adds value by explaining 'The Smartmeter's device serial number (see list_smartmeters or list_devices).' This cross-reference aids the agent in obtaining the correct parameter, which goes beyond the schema's minimal title.

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 purpose: 'Get current status for one Smartmeter: grid import/export power and any other fields the Anker cloud API reports for this device.' It uses a specific verb (Get) and resource (Smartmeter status), distinguishing it from sibling tools like list_smartmeters or get_solarbank_status.

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?

The description does not explicitly state when to use this tool versus alternatives. It mentions retrieving status for one Smartmeter but lacks comparison to sibling tools like get_site_overview or get_solarbank_status. The parameter hint to see list_smartmeters or list_devices provides indirect context but no clear usage boundaries.

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

get_solarbank_scheduleB

Get the charge/discharge schedule and output-power plan configured for a Solarbank, if the Anker cloud API reports one under this device's cached data.

    Args:
        device_sn: The Solarbank's device serial number (see list_solarbanks
            or list_devices).

ParametersJSON Schema

Name	Required	Description	Default
`device_sn`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It mentions 'cached data', implying a non-live query, but does not disclose side effects (e.g., read-only), permissions, or error conditions. This is insufficient for a tool with no annotations.

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

Conciseness3/5

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

The description uses a docstring format with Args section, which is structured but somewhat verbose. It could be more concise while retaining clarity.

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

Completeness2/5

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

Given the tool has an output schema, the description does not need to explain return values, but it omits important context such as what happens if no schedule is found (e.g., null or error), prerequisites like permissions, and behavior under error conditions. The mention of 'cached data' is helpful but incomplete.

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 0% schema description coverage, the description adds valuable context by explaining that device_sn is the 'Solarbank's device serial number' and references list_solarbanks or list_devices for obtaining it. This goes beyond the schema's minimal 'Device Sn' title.

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 specifies the verb 'Get' and the resource 'charge/discharge schedule and output-power plan' for a Solarbank. It distinguishes itself from sibling tools like get_solarbank_status, which deals with status rather than schedule.

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?

The description mentions the schedule is returned 'if the Anker cloud API reports one under this device's cached data', which hints at conditional existence but provides no explicit guidance on when to use this tool versus alternatives like get_solarbank_status. No when-not or alternative tools are suggested.

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

get_solarbank_statusA

Get current status for one Solarbank (or expansion battery pack): battery state of charge, solar input power, output power, charge/discharge power, temperature, and any other fields the Anker cloud API reports for this device.

    Args:
        device_sn: The Solarbank's device serial number (see list_solarbanks
            or list_devices).

ParametersJSON Schema

Name	Required	Description	Default
`device_sn`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries full burden and clearly explains the tool's read-only nature and returned fields. It honestly states it reports 'any other fields the Anker cloud API reports', setting expectations for dynamic schema. No contradictions detected.

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 concise, front-loading the main purpose and key details. Every sentence adds value, though it could be slightly more structured with bullet points. Overall efficient.

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 tool's simplicity, output schema exists to cover return values, and the description lists key fields. It provides enough context for an agent to use correctly, though error handling or invalid SN behavior is not addressed.

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 0%, so the description must compensate. The parameter device_sn is described with its source (list_solarbanks or list_devices) and purpose, adding meaningful context beyond the schema. However, format or constraints are not specified.

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 verb 'Get' and the resource 'current status for one Solarbank or expansion battery pack', listing specific fields. It distinguishes from sibling tools like list_solarbanks by focusing on a single device's status.

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?

The description implicitly indicates usage for retrieving Solarbank status but does not provide explicit when-to-use or when-not-to-use guidance compared to siblings like get_device. It suggests obtaining the serial number from list_solarbanks or list_devices, which is helpful context.

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

list_devicesA

List every device (Solarbank, expansion battery pack, Smartmeter, etc.) linked to the Anker account, keyed by device serial number.

    Each entry contains whatever fields the Anker cloud API reports for
    that specific device model and firmware version - typically at least a
    name and a type/model field, plus live status fields where available.
    Use this to find device serial numbers (device_sn) for the more
    specific tools like get_solarbank_status and get_smartmeter_status.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

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

Describes that entries contain whatever fields the API reports, typically name, type/model, and live status fields. This informs the agent about variability and typical content. No annotations, so description carries full burden.

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?

Well-structured with main action front-loaded. Some verbosity but each sentence adds value. Could be slightly more concise.

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 zero parameters and presence of output schema, the description adequately explains what entries contain and the tool's purpose, linking to sibling tools. No missing critical info.

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?

No parameters, so schema coverage is 100%. Description does not need to add parameter info. Baseline for zero parameters is 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?

Clearly states it lists all devices linked to the Anker account, keyed by serial number, with specific device types. Also distinguishes itself by mentioning it helps find serial numbers for more specific 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?

Explicitly says to use this to find device serial numbers for specific tools like get_solarbank_status and get_smartmeter_status, providing clear context for when to use it. Does not explicitly state when not to use, but the guidance is sufficient.

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

list_sitesA

List every Anker power system ("site") linked to this account, keyed by site ID.

    A site groups together the devices installed at one location - e.g. a
    Solarbank, its expansion battery pack, and a Smartmeter. Start here (or
    with list_devices) to discover the IDs needed by the other tools.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description bears the full burden. It accurately describes a read-only list operation with no side effects. While it doesn't mention rate limits or authentication, the behavior is simple and straightforward, and the description adds the context of what a site represents.

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 with no fluff. It front-loads the action ('List every Anker power system...'), then provides context and a usage tip. Every sentence earns its place.

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 the presence of an output schema, the description does not need to detail return values. It provides enough context about the grouping concept and how to use the tool as a starting point, making it complete for the tool's simplicity.

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?

There are no parameters, and schema coverage is 100% trivial. The description adds meaning beyond the schema by explaining that the result is a list keyed by site ID and what a site represents, which is valuable context for an agent.

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 lists every Anker power system (site) linked to the account, keyed by site ID. It explains what a site is (group of devices at one location) and distinguishes from siblings like list_devices, which lists devices rather than sites.

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 (or with list_devices) to discover the IDs needed by the other tools,' providing clear guidance on when to use this tool as an entry point and offering an alternative. It does not specify conditions for not using it, but the context is clear.

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

list_smartmetersA

List devices that look like Anker Smartmeters, identified heuristically from model/type/name fields.

If nothing matches the heuristic, every device is returned instead so you can still find the right one by eye.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.5/5.0

Behavior4/5

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

Discloses heuristic-based filtering and fallback behavior. No contradictions with annotations (none provided). Covers key behavioral aspects for a read-only tool.

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, front-loaded with purpose. No wasted words.

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 0-parameter tool with output schema, the description fully explains behavior. No missing context.

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?

No parameters, so baseline 4. Description adds context beyond schema (heuristic and fallback logic).

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?

Description clearly states it lists devices matching a heuristic for Anker Smartmeters, distinguishing it from sibling list_devices (which likely returns all devices).

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 describes fallback to all devices if no match, guiding user on what to expect. Could be stronger by stating when to prefer over list_devices.

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

list_solarbanksA

List devices that look like Solarbanks or their expansion battery packs, identified heuristically from model/type/name fields.

    If nothing matches the heuristic, every device is returned instead so
    you can still find the right one by eye - use get_device on any
    serial number for the unfiltered detail record.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.7/5.0

Behavior4/5

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

Describes heuristic identification and fallback to returning all devices, but does not explicitly state it is read-only or non-destructive. Since annotations are missing, the description could be slightly improved by noting it has no 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?

Four sentences with no wasted words; first sentence immediately states the core purpose. Information is front-loaded and efficient.

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?

Complete for the tool's simplicity: no parameters, has output schema, and the description covers behavior, fallback, and guidance for further action. No gaps.

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?

No parameters exist, so the description correctly adds no parameter details. Baseline score applies as schema coverage is 100% vacuously.

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 lists devices identified as Solarbanks or expansion battery packs using heuristic matching on model/type/name fields, distinguishing it from the sibling tool list_devices which lists all devices without filtering.

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 explains when to use (to find Solarbanks) and what to do if no match (use get_device on any serial number for unfiltered detail), providing clear alternatives and fallback behavior.

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

refresh_dataA

Force an immediate refresh of all cached Anker Solix data (sites, devices, and energy), bypassing the normal refresh-interval throttle.

Call this if you suspect other tools are returning stale data - for example right after changing a setting in the Anker app.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses bypassing the normal refresh throttle, a key behavior. However, it does not mention potential side effects like rate limiting or whether the refresh is per-user or global. Additional behavioral context would improve transparency.

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 short sentences with no extraneous words. The first sentence defines the core action, the second adds usage guidance. Perfectly front-loaded and efficient.

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?

For a simple tool with no parameters and an output schema, the description covers purpose, usage context, and a behavioral trait. It lacks details like confirmation of success or failure handling, but overall is thorough enough for an agent to use correctly.

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 input schema has zero parameters, so baseline is 4. The description adds value by explaining what the tool does (forces refresh of all cached data) beyond the empty schema, making the semantics clear.

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 forces an immediate refresh of all cached Anker Solix data (sites, devices, energy) bypassing the throttle. This is a specific verb+resource combination with clear scope, distinguishing it from sibling read-only 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?

Explicitly says to call when suspecting stale data, e.g., after changing settings in the Anker app. This provides clear context for use, though no explicit alternatives are mentioned, but siblings are all read functions, making this the sole refresh tool.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

12 tool updatesv0.1.0Jul 15, 2026
- First observedget_account_info
- First observedget_device
- First observedget_energy_statistics
- First observedget_site_overview
- First observedget_smartmeter_status
- First observedget_solarbank_schedule
- First observedget_solarbank_status
- First observedlist_devices
- First observedlist_sites
- First observedlist_smartmeters
- First observedlist_solarbanks
- First observedrefresh_data

Deploy Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Scored 2026-07-15 13:15 across 12 tools

Disambiguation5/5

Each tool targets a distinct aspect of the Anker Solix system, with clear separation between listing, status, schedule, and data refresh tools. No two tools have overlapping purposes; even the similar get_solarbank_status and get_solarbank_schedule are clearly differentiated by retrieving status vs. schedule.

Naming Consistency4/5

Tools consistently use a verb_noun pattern: get_ for detail retrieval and list_ for enumeration. The only outlier is refresh_data, which does not follow the get_/list_ convention, slightly breaking consistency.

Tool Count5/5

With 12 tools, the server is well-scoped for monitoring an Anker Solix system. It covers all necessary operations without being overwhelming, and each tool serves a clear, non-redundant purpose.

Completeness4/5

The tool set provides comprehensive read access to account info, sites, devices, status, energy statistics, and schedules. However, it lacks write operations (e.g., setting schedules, controlling devices), which may be expected for a full management interface, but given the apparent monitoring focus, the coverage is strong.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

keithah-tessie-mcp
ai.smithery
Unofficial integration! ## ✨ Key Features ### 💰 Financial Intelligence - **Smart Charging Cost An…
Finance Travel & Transportation App Automation
27
Era ContextOAuth
app.era
Personal finance, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
Finance Knowledge & Memory
1
glim.sh A
sh.glim
Give your agent live data from Twitter, Reddit, the web and GitHub. No API keys, no scraping stack.
Browser Automation Social Media Version Control
1434
Elecz Electricity Price Signal API A
io.github.zemloai-ctrl
Real-time electricity prices for AI agents. 40+ countries, 100+ zones. No auth required.
Energy Home Automation & IoT Research & Data
323

Related MCP Servers

emsesp-mcp-serverofficial
Home Automation & IoT Energy
bosch-buderus-wp
A
license
Not graded
quality
C
maintenance
Enables LLM applications to query and visualize data from Bosch/Buderus heat pumps via ems-ESP, including temperatures, statistics, and heat curves through natural language.
Updated a year ago (2025-07-20 08:02 UTC)
9
MIT
fronius-mcp
Energy Home Automation & IoT
flowiesner
A
license
A
quality
D
maintenance
Enables real-time solar data from Fronius inverters via Claude, allowing natural language queries about solar production, battery, and grid exchange.
Updated 5 months ago (2026-04-18 13:31 UTC)
5
1
Apache 2.0
Fronius MCP Server
Energy Home Automation & IoT
huber
A
license
A
quality
C
maintenance
Enables access to Fronius solar inverter data via the MCP protocol, allowing real-time monitoring of energy production, consumption, and battery storage through natural language.
Updated 10 months ago (2025-11-24 10:16 UTC)
14
8
4
MIT
tibber-mcp-server
Energy Home Automation & IoT
Schimmilab
A
license
A
quality
A
maintenance
Enables querying Tibber electricity prices, forecasts, consumption data, cheapest hours, and live Pulse measurements through natural language.
Updated a day ago (2026-09-11 08:04 UTC)
7
MIT

Anker Solix MCP Server

Contents

How this fits together

Repository structure

Prerequisites

Installation

Configuration

Running the server standalone

Connecting to an MCP client

Claude Code

Claude Desktop

Cline

Any other MCP host

Running over HTTP

Starting it

What changes vs. stdio, and what to consider

Available tools

Design notes

Development

Continuous integration & security

Extending

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

emsesp-mcp-serverofficial