SolMachina's own Solana epoch-transition checkpoint series: the live epoch/slot reading (getEpochInfo via multi-RPC) measured against our accumulating on-disk series to yield a MEASURED slot-rate + ETA (not a model) and last epoch-transition detection. Optional ?n sets how many recent series points to return.
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | How many most-recent series points to include in `series.recent`, 1-200 (default 20). |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does a solid job: it explains the live multi-RPC reading, the peristence via on-disk series, the measurement-based nature, and the optional output size. It does not explicitly state read-only behavior, but no mutating action is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense but informative sentence, with the key purpose front-loaded and the optional parameter mentioned at the end. It is concise, though the parentheticals make it slightly less clean than ideal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple optional parameter and no output schema, the description gives enough context: it identifies what is measured, what is returned conceptually, and the optional n effect. It could be more explicit about output formatting, but it is adequate for the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter n is fully described in the schema, and the description repeats that it is optional and controls return count. No additional semantic meaning beyond the schema is provided, so this is at the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific purpose: providing a measured Solana epoch-transition checkpoint series derived from live getEpochInfo data, yielding slot-rate, ETA, and last epoch-transition detection. It is distinct enough from related tools, though it does not 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing implies use when a measured, not modeled, epoch-transition analysis is needed, and it mentions the optional n parameter. However, it does not explicitly state when to choose this tool over sibling tools or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.