anker-solix-mcp

Server Quality Checklist

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

Latest release: v0.1.0
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.
Average 4.2/5 across 12 of 12 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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

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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

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:

[![anker-solix-mcp MCP server](https://glama.ai/mcp/servers/gkoenig/anker-solix-mcp/badges/card.svg)](https://glama.ai/mcp/servers/gkoenig/anker-solix-mcp)

Score Badge

Copy to your README.md:

[![anker-solix-mcp MCP server](https://glama.ai/mcp/servers/gkoenig/anker-solix-mcp/badges/score.svg)](https://glama.ai/mcp/servers/gkoenig/anker-solix-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/gkoenig/anker-solix-mcp'

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