Emer Ai Tools

This connector has been deprecated

Moved to com.steledger/gateway — same service, now at https://api.steledger.com/mcp

Node status

node_status

Read-onlyIdempotent

Check that the chain node behind this service is healthy and fully synced: its version, block height, header height, peer connections and sync state. It is an Emercoin node. Read-only, no sign-in required, no parameters.

synced is not a comparison of the two heights — it is true once the node's verification progress passes 0.9999, so it can still be false while blocks and headers already match. Trust that field, not the arithmetic. While it is false, a read_record may reflect an older state of the chain; writes still work, they simply confirm later.

Also the way to make sense of expiry: expires_in on a record is denominated in blocks, and this tool reports the current height, so the two together are the only authoritative answer to when something lapses. A term is bought in days and charged at a flat 175 blocks each; the chain has been producing about 171 a day lately (8.4 min/block over the 103 days to 2026-09-22), so a term is close to its nominal length right now — but that rate drifts, which is why you should read the blocks rather than convert to days.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
`blocks`	No
`synced`	No
`headers`	No
`version`	No
`connections`	No
`verificationprogress`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 24, 2026
- addedOutput schema / description
```
Added value: +"Node sync status. Fields are nullable: the node may report any of them as null."
```
- removedOutput schema / properties / blocks / default
```
Removed value: -null
```
- removedOutput schema / properties / connections / default
```
Removed value: -null
```
- removedOutput schema / properties / headers / default
```
Removed value: -null
```
- removedOutput schema / properties / synced / default
```
Removed value: -null
```
- removedOutput schema / properties / verificationprogress / default
```
Removed value: -null
```
- removedOutput schema / properties / version / default
```
Removed value: -null
```
First observedJun 15, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, but the description adds real substance: no sign-in, the counterintuitive `synced` semantics (driven by verification progress, not height equality), and the fact that reads may lag while writes still succeed. It stops short of describing response shape or node-failure behavior, but that is largely covered by the output schema.

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?

Purpose and the key `synced` caveat are front-loaded well, but the final paragraph spends several sentences on block-rate arithmetic (175 blocks, 8.4 min/block, 103 days to 2026-09-22) that is background trivia for a tool that simply returns heights. The core advice — read blocks, don't convert to days — could be one sentence.

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?

With an output schema present and no parameters, the description covers everything an agent needs: what is reported, that no auth or args are required, and how to interpret the one ambiguous field. Nothing material is missing 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?

Zero parameters, so the baseline is 4; the description correctly states 'no parameters', confirming the agent needs to supply nothing.

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 a specific verb and resource — check the chain node's health and sync state — and enumerates exactly what is returned (version, block height, header height, peers, sync state). An agent can immediately tell this apart from the record-oriented siblings like list_records and read_record.

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 frames usage: call it to judge whether read_record results may be stale while `synced` is false, and to combine with a record's `expires_in` (denominated in blocks) to answer expiry questions. It also warns against converting to days instead of reading block height, which is an explicit when-to / when-not.

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

All Emer Ai Tools tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?