mcp-fsolar

Server Quality Checklist

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

Latest release: v1.0.42
Disambiguation4/5
Most tools target distinct scopes: fleet vs battery vs cell-level, raw vs statistics, health vs history. However, get_health, get_module_health, get_cell_stats, get_cell_voltages, and get_balance_trend all touch on cell/module health and could be confusing without careful reading, though descriptions clarify granularity.
Naming Consistency5/5
All tool names follow a consistent get_ + noun pattern, using snake_case for compound names. There are no mixed conventions or vague verbs, making the naming predictable and uniform.
Tool Count3/5
With 17 tools, the server sits in the 16–25 range, feeling somewhat heavy for a monitoring API. While each tool serves a specific data need, the count could be trimmed by merging closely related health/cell tools without losing functionality.
Completeness4/5
The read-only monitoring surface is fairly complete: live status, health, alerts, energy history, capacity estimates, power stats, cost savings, and lifetime data are all covered. Minor gaps include lack of a dedicated temperature history or per-module raw voltage detail, but these are workarounds via snapshots.
Average 3.8/5 across 17 of 17 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 38 commits in the last 12 weeks
- Last stable release on July 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It lists included fields but does not explain what the summary aggregates (e.g., fleet-wide vs. per battery), units, or how metrics like 'worst cell imbalance' are calculated. This is minimal behavioral disclosure.
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 a single, front-loaded sentence that directly states the tool's output type and contents. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple summary tool with no output schema, the description lists the key fields, which is helpful. However, it lacks context on the scope (fleet vs. individual), units, and output structure, leaving some ambiguity for the agent about exactly what will be returned.
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 tool has zero parameters, and the schema is empty. The description adds no parameter information, but none is required. The baseline for zero-parameter tools is 4, and no deduction is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a 'Compact health summary' and specifies the key fields: total energy, worst cell imbalance, and temperatures. While the verb 'get' is not explicitly restated, the intent is clear, and the content distinguishes it from per-battery tools via the 'fleet' scope.
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?
No guidance is given on when to use this tool versus alternatives such as get_health or get_cell_stats. The description does not mention exclusions, prerequisites, or comparison to sibling tools, leaving the agent to infer applicability from the name alone.
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 are provided, so the description must carry the behavioral burden. It accurately lists the report contents, which implies a read-only operation, but it does not explicitly state read-only behavior, error conditions, or any side effects. The listing covers the main output but omits edge-case behavior.
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 a single, front-loaded sentence that efficiently lists all key report elements without unnecessary words. Every item earns its place, and the structure is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one optional parameter, no output schema, and no annotations, the description gives a good outline of the report's contents but does not describe the return format or structure (e.g., object fields vs. list). It is sufficient for basic understanding but lacks some details a caller might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% description coverage for the single optional parameter 'id' (alias/serial number, omit for all batteries). The description adds only the notion of 'per-battery' scope, which is already implied by the schema. Baseline 3 is appropriate since the schema fully documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a 'per-battery health report' and enumerates specific data elements (cell delta status, temperature status, SOH, weak/outlier cell indices, average C-rate, discharge-phase delta). This distinguishes it from broader tools like get_battery and get_fleet_summary, though it could explicitly name sibling alternatives.
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 gives no guidance on when to use this tool versus sibling tools such as get_cell_stats or get_module_health. It does not mention any exclusions or alternatives, leaving the agent to infer usage from the content list.
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 are provided, so the description carries the full burden of behavioral disclosure. It does explain that the tool computes aggregates from live cell voltages and flags modules with persistent outlier cells, which is useful. However, it does not explicitly state that the operation is read-only, define 'persistent', or describe the return format. Given the absence of annotations, this is a partial disclosure.
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 a single, compact sentence with two meaningful clauses: one stating the main output and one highlighting the outlier flagging feature. Every word adds value, and the most important information is front-loaded. No redundant or filler 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, no output schema, no nested objects), the description is reasonably complete. It conveys the core output and a distinctive feature, though it leaves 'persistent' and 'delta' undefined. For a one-parameter get operation, this is adequate but leaves slight ambiguity about edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter 'id' is described as 'Alias (Bat1/Bat2/Bat3) or serial number'. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it produces per-module voltage aggregates (min/max/mean/delta) and flags modules with persistent outlier cells. It specifies the resource ('one battery') and differentiates from siblings like get_cell_stats by focusing on module-level aggregation and outlier flagging. Although it lacks an explicit verb like 'returns' or 'gets', the meaning 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (checking module health from live cell voltages) but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among the many sibling tools. Without such guidance, an agent may not know to choose this over get_cell_stats or get_cell_voltages for related needs.
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 are provided, so the description carries the full burden. It discloses the data source (intraday snapshots) and the computed statistics, implying read-only behavior, but does not state side effects, performance characteristics, or any limitations.
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 a single, information-dense sentence that front-loads the purpose and lists concrete outputs without wasted words. It is appropriately sized 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 simple one-parameter schema and absence of an output schema, the description covers what the tool returns but does not detail the response shape or units. However, it is sufficient for a basic stats tool and adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter 'id' as 'Alias (Bat1/Bat2/Bat3) or serial number' with 100% coverage. The description adds no additional meaning or context for the parameter, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the resource (per-cell voltage) and the exact outputs (mean, stddev, min/max, deviation from pack average, trend direction). This distinguishes it from sibling tools like get_cell_voltages and get_balance_trend, making the purpose unambiguous.
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?
No explicit guidance is given on when to use this tool versus alternatives. The phrase 'from intraday snapshots' provides some context, but there is no mention of when not to use it or which sibling tools to prefer for other needs.
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 the burden. It adds context by noting the projection is for LFP batteries and based on nominal 4000 cycles, which is a useful behavioral detail. It doesn't explicitly state that the operation is read-only or describe any error conditions, but the 'get' prefix implies read-only, and there are no side effects to disclose. Overall it provides some additional behavior context beyond a bare list.
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 a single, tightly packed sentence listing exactly the returned metrics with no filler or repetition. Each item (cycle count, events, warning count, projected life) is substantive, and the nominal-4000-cycles qualification adds precision without extra 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 covers the return values comprehensively, serving as a de facto output schema for a tool with no output schema. It also provides the LFP-specific projection context. It doesn't specify numeric units or time periods, but the simple nature and optional parameter make this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the only parameter 'id' is 100% comprehensive, explaining alias/serial and the default behavior when omitted. The tool description adds no additional parameter guidance, so it relies on the schema, which is already strong. Baseline 3 applies since schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description enumerates the key lifetime metrics (cycle count, events, warning count, projected LFP cycle life), making clear this is a getter for battery lifetime stats. It distinguishes from siblings like get_health and get_autonomy by focusing on lifetime-specific data. However, it lacks an explicit verb such as 'Retrieves' and is just a noun phrase, which slightly reduces clarity.
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 implies usage when lifetime statistics are needed, but it doesn't provide explicit when-to-use or when-not-to-use guidance or reference alternative sibling tools. It doesn't mention that get_health would be more appropriate for health-specific queries, so guidance is only implied by the metric list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 does not state whether the tool is read-only, whether it involves any side effects, or any prerequisites such as recent snapshot availability. It only describes the output metrics and data source, leaving operational behavior unclear.
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 a single, well-structured sentence that front-loads the core purpose and lists the specific metrics returned. There is no wasted verbiage, and every phrase adds value.
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 zero-parameter, read-only tool with no output schema, the description is reasonably complete. It lists all the computed metrics and the data source. It does not explain the exact time range covered by 'intraday' or how to interpret the values, but given the tool's simplicity, this is a minor gap.
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 tool has zero parameters, so the input schema is empty. According to the rubric, a baseline score of 4 is appropriate when there are no parameters, as the description does not need to compensate for missing schema info. The description provides context about what the returned stats represent, which is sufficient.
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 what the tool returns: charge/discharge power statistics including peak kW, average kW, C-rate, and fraction of samples above 0.5C. It also specifies the data source (intraday snapshots), making it distinct from sibling tools like get_cell_stats or get_lifetime_stats.
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 provides no explicit guidance on when to use this tool vs alternatives. It mentions 'from intraday snapshots' as a data source, but does not say when this tool is preferable to get_energy_history or get_cell_stats, nor are any exclusions or alternatives named.
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 must carry behavioral disclosure on its own. It communicates that the data is 'live' and lists the provided fields, which implies a read-only status query. However, it does not explicitly state whether the operation is side-effect-free or if any caching or rate limits apply.
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 a single, well-structured sentence that front-loads the core purpose and lists the key data fields. Every word contributes useful information with no redundancy or fluff.
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 there is no output schema, the description provides a helpful field list (SOC, power, voltage, temperature, charging state) that conveys the return content. It is slightly incomplete because it does not explicitly state that the result is an array of battery statuses, but the phrase 'all batteries' strongly implies that structure.
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 tool has zero parameters, so there is nothing to clarify. The description's mention of the returned metrics fully covers the only meaningful semantic content, matching the baseline of 4 for parameterless tools.
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 returns the live status of all Felicity batteries, listing specific metrics (SOC, power, voltage, temperature, charging state). This distinguishes it from siblings like get_battery (single battery) and get_health (health-focused) by scope and content.
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 gives no explicit guidance on when to use this tool versus alternatives. While 'all batteries' implies a fleet-wide view, it does not mention specific use cases or contrast with sibling tools such as get_battery or get_fleet_summary.
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 are provided, so the description carries the full burden. It discloses the core behaviors (estimating time to discharge/charge, optional projection) but does not explicitly state that the tool is read-only or safe to call, nor does it mention edge cases like missing parameters. The low risk of a 'get' tool mitigates this, but the description could be more explicit.
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 a single, front-loaded sentence that conveys all essential information without extraneous words. It is concise and well-structured, making it easy for an agent to quickly grasp the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is largely complete for a read-only estimation tool with three optional parameters. It explains the main outputs and the optional projection feature, but it does not mention what happens when optional parameters are omitted or any limitations. Given the simplicity of the tool, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds semantic context by linking minSocPct to 'minSoc' and sunriseAt to the 'SOC projection', but it does not provide additional syntax or format details beyond what the schema already states. No extra value beyond the existing parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a fleet autonomy estimate, specifically hours until minSoc and hours to full charge, plus an optional SOC projection. This is a specific verb+resource pairing that distinguishes it from sibling tools like get_health or get_energy_history.
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 implies usage for fleet autonomy assessment, but it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions. Since sibling tools cover different aspects (health, alerts, energy), the implicit context is sufficient but lacks explicit guidance.
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 are provided, so the description carries the burden. It states the tool returns 'detailed status' but does not disclose what fields are included, whether the operation is read-only (though 'get' implies it), or any error/edge-case behavior. For a simple read tool, this is adequate but lacks depth.
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 a single sentence that is direct and front-loaded with the core purpose. No unnecessary words or repetition. It is optimally 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?
The tool is simple with one required parameter and no output schema. The description covers the core purpose and identification method, making it largely usable. However, 'detailed status' is vague about the exact contents of the response, which could be an issue for an agent expecting a specific structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'id' parameter with 100% coverage. The description restates the same alias/serial number info without adding new details such as examples, formatting, or constraints. Baseline 3 is appropriate because the schema handles the semantics.
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 retrieves detailed status for one battery, specified by alias or serial number. This distinguishes it from sibling tools like get_all_batteries (multiple batteries) and get_cell_stats (specific stats). The verb 'get' and resource 'status' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single battery's detailed status but does not explicitly contrast with alternatives like get_all_batteries or get_health. There is no when-not-to-use guidance, so the usage context is implied rather than stated.
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 are provided, so the description carries the full burden. It discloses the unit (mV) and scope (one battery), and the read-only nature is implied by the name 'get'. However, it doesn't mention return format, error conditions, or any side effects. The context is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first front-loads the main purpose, and the second adds a use case. No wasted words, and the structure is easy to scan.
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 one-parameter getter with no output schema, this description provides enough context: what data is returned (cell voltages in mV), scope (one battery), and a use case. It lacks detail about the exact return structure (e.g., array with cell indices), but the simplicity of the tool makes this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% because the 'id' parameter has a description ('Alias (Bat1/Bat2/Bat3) or serial number'). The description adds no parameter-level information, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (individual cell voltages in mV) and scope (one battery), and adds a use case for imbalance detection. However, it lacks an explicit verb (e.g., 'returns' or 'lists'), relying on the tool name 'get' to convey the action, and does not explicitly distinguish from sibling tools like get_cell_stats.
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 a clear context for when to use this tool: 'Useful for detecting cell imbalance.' It does not mention alternatives or exclusions, but the use case is specific enough to guide an agent. Without naming when not to use it, it falls short of a 5.
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 full burden of disclosure. It reveals useful behavioral details: the snapshots are raw, cover the last ~60 minutes, are sampled every ~10 minutes, and include cell voltages, delta, SOC, and balancing state. It does not explicitly state that it is read-only, but the 'raw snapshot' phrasing implies observation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded, and every clause contributes meaning: time window, cadence, and content. No filler or irrelevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description sufficiently explains what is returned, the time range, and the sampling interval. It supports confident tool selection without requiring additional detail.
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 coverage is vacuously 100%. The baseline for zero-parameter tools is 4, and the description does not need to add parameter semantics because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns raw battery pack snapshots for the last ~60 minutes, with a specific cadence of one per ~10 minutes, and lists the included metrics. This distinguishes it from siblings like get_cell_voltages or get_balance_trend, though it does not explicitly contrast with them.
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 provides no guidance on when to use this tool versus the many sibling get_* tools. There are no explicit alternative recommendations or conditions for use, so the agent must infer from the raw snapshot context alone.
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 must carry the burden of explaining behavior. It does specify what checks are performed and that the list is ranked, but it lacks details about return structure, staleness criteria, or whether the operation is read-only (though 'get' implies safe). It provides some context but not comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the primary purpose, and efficiently lists the checks. 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?
For a simple one-parameter tool with no output schema, the description covers the main context: what the alert list contains, how it is ordered, and the optional filtering. It could benefit from noting response format or sorting order beyond severity, but overall it is adequate for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the 'id' property is fully described). The description does not add extra parameter semantics but also does not need to since the schema already explains the alias/serial and optional omission.
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?
Clear verb and resource: 'get_alerts' with description specifying an 'Active alert list ranked by severity.' It distinguishes itself from sibling tools by enumerating specific alert types (cell imbalance, temperature, SOH, etc.) rather than general health or stats.
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 states it returns active alerts ranked by severity, clarifying when to use it (for current alerts). It does not explicitly mention alternatives or exclusions, but the context is clear enough for a straightforward list tool.
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 discloses the time window and the nature of the output (categorical status). It does not reveal whether the tool is purely read-only, but the 'get' prefix implies that. It also doesn't mention any potential side effects or additional behavior like pagination or data freshness, which would be relevant.
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 consists of two short sentences, both informative and free of filler. It front-loads the core purpose and then clarifies the output meaning, making it highly 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?
The tool is simple with one optional parameter, and the description conveys the purpose and output interpretation. However, without an output schema or more detail on the return format (e.g., whether it's a time series or just a single classification), there is slight ambiguity. Overall it's adequate for a basic monitoring tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage for the single 'id' parameter, including allowed formats and the default for omission. The description adds no extra parameter-related details, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a balance trend for batteries over the last ~60 minutes and defines the output as a categorical assessment (improving, stable, degrading). This distinguishes it from sibling tools like get_cell_stats or get_snapshots by focusing on trend classification rather than raw 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 gives context that this is for assessing balance trend over a recent 60-minute window, implying it's useful for monitoring battery health. However, it doesn't explicitly state when to use this instead of alternatives like get_cell_stats or get_energy_history, nor does it mention exclusions.
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 defines the computed metric but doesn't disclose behavioral details such as return format, units, or behavior for multiple batteries. It implies a read operation but lacks explicit safety/permission context. The definition adds some transparency but leaves 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?
Two short sentences: the first defines the tool's output, the second gives a use case. No fluff, front-loaded.
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 getter with one optional parameter and no output schema, the description covers the core purpose and situational context. It could mention specific output details, but it's adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes the single optional 'id' parameter with 100% coverage ('Alias (Bat1/Bat2/Bat3) or serial number; omit for all batteries'). The description does not add parameter information, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the metric as 'Headroom between current voltage/current and BMS protection limits,' which is specific to this tool and distinguishable from sibling get_* tools (e.g., get_health, get_cell_stats). The noun phrase effectively communicates the tool's function, and the tool name 'get_limit_headroom' reinforces it.
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 states it's 'useful for spotting packs running close to cutoff thresholds,' providing a clear use case. It doesn't explicitly exclude alternatives, but the context is sufficient for an agent to select this tool when monitoring limit proximity.
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 must carry the full burden, and it does so by disclosing the calculation method and the SOC accuracy limitation. It does not explicitly state that the operation is read-only or describe output format, but the 'get' name and 'estimates' phrasing imply a non-mutating calculation.
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 tight sentences lead with the tool's purpose, followed by a key accuracy condition. Every word contributes meaning, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool shape (one optional parameter, no output schema, no annotations), the description provides adequate context about purpose, formula, and accuracy. It doesn't specify the exact return format, but 'per battery' and the formula give a sufficient indication of what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single optional parameter 'id' with its accepted values (alias or serial number) and default behavior (omit for all batteries). The description adds no additional parameter semantics, so it falls at the baseline for 100% schema coverage.
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 function: estimating real usable capacity via a specific formula (remainingKwh ÷ SOC%) and comparing it to rated capacity per battery. This distinctly sets it apart from sibling tools that measure other battery metrics such as health or autonomy.
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 a clear usage context by noting that the estimate is most accurate at 20–80% SOC, implying when the tool should be used for reliable results. It does not explicitly name alternative tools, but it offers a condition that guides appropriate usage.
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?
The description explains the calculation and the tariff input options, but with no annotations it carries the full burden. It does not disclose what happens if neither tariffKwh nor the env var is provided, nor does it mention output format or that it is a read-only calculation. The formula and input dependency are clear, but behavior under missing input is left undetermined.
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?
One concise sentence front-loaded with the tool's purpose and the input requirement. No wasted words or redundant 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?
For a simple tool with one optional parameter, the description covers purpose, calculation, and input mechanism. It lacks a note on fallback behavior when no tariff is provided, but overall it is sufficiently complete given the tool's simplicity and the rich sibling tool 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?
Schema already fully describes tariffKwh (coverage 100%), so baseline is 3. The description adds value by introducing the FELICITY_TARIFF_KWH environment variable as an alternative source and by clarifying the parameter's role in the savings formula, which goes beyond the schema's basic unit description.
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: 'Estimated monetary savings from discharged energy × electricity tariff.' It specifies the exact formula and the resource (cost savings), distinguishing it from sibling tools about health, autonomy, and energy history.
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?
Provides clear usage context: 'Pass tariffKwh or set FELICITY_TARIFF_KWH env var.' This explains how to invoke the tool with the necessary input. However, it does not explicitly discuss when to prefer this over alternatives, though none of the sibling tools overlap with cost savings.
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 discloses the data source (persistent store), time range (up to 90 days), and merging behavior with live intraday data. It adds useful context but stops short of explaining the merge mechanics or what 'peak rates' specifically include, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and free of redundancy. Each clause adds value, covering scope, data source, and output fields efficiently.
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 0-parameter tool with no output schema, the description covers the essential aspects: content, units, time window, and additional outputs. Minor gaps include the exact nature of the merge and return format, but it is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, so there are no parameters requiring explanation. The description adds no parameter-level detail, but this is unnecessary given the zero-parameter design; baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing daily charge/discharge energy totals in kWh, with a 90-day range and additional metrics such as peak rates and net balance. This distinguishes it from siblings like get_power_stats or get_lifetime_stats by specifying temporal granularity and data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use: it returns daily energy totals over up to 90 days, merging historical and intraday data. While it does not explicitly name alternatives or exclusions, the context strongly implies the intended use case for historical daily aggregation.
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:

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

Score Badge

Copy to your README.md:

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

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/RicardoSantos/mcp-fsolar'

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