Skip to main content
Glama
chanyou0311

aiseg2-mcp

by chanyou0311

get_cost_history

Read-onlyIdempotent

Query long-term energy-cost history from an AiSEG2 SD card, returning cost points in Japanese yen. Filter by day, month, or year granularity.

Instructions

Read-only. Query the AiSEG2's long-term energy-cost history from the SD-card export (JPY).

Requires an SD card inserted in the AiSEG2. Shares the same cached download as get_history.
Returns long-form cost points ({timestamp, metric, value}) with values in Japanese yen.

Args:
    granularity: "day" takes start/end as YYYY-MM-DD; "month" as YYYY-MM; "year" as YYYY.
    start: Range start (inclusive), formatted per the granularity.
    end: Range end (inclusive), formatted per the granularity.
    limit: Maximum number of series points to return (default 200).
    offset: Number of points to skip (for pagination).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endYes
limitNo
startYes
offsetNo
granularityYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
unitYes
seriesYes
has_moreYes
total_rowsYes
granularityYes
next_offsetNo
Behavior4/5

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

Beyond annotations (readOnly, idempotent), adds unique behavioral details: SD card requirement, cached download sharing with get_history, and return format with JPY values. No contradictions with annotations.

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

Conciseness5/5

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

Efficiently structured with purpose first, then requirements, then return format, then args. Every sentence adds value; no fluff.

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 output schema and annotations, the description covers purpose, dependencies, return shape, and all parameters thoroughly. No significant gaps for an agent to misuse.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has no descriptions, so the Args section compensates fully: explains granularity formats, inclusive ranges, limit default, and offset pagination. Adds meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States specific purpose: querying long-term energy-cost history from SD-card export. Distinguishes from sibling get_history by noting cache sharing and cost-specific focus.

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 context: requires SD card, read-only, shares cached download with get_history. Does not explicitly name exclusions but implies usage for cost history queries.

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

Install Server

Other Tools

Latest Blog Posts

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/chanyou0311/aiseg2-mcp'

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