Skip to main content
Glama

Seneschal Data

by io.github.Rotwang9000
OverviewDiscussionsAdmin

Penny Oracle: atomic single-fact endpoints (privacy chains + Ethereum gas)

seneschal_q

Atomic single-fact endpoints designed for tight agent loops. Each answers ONE yes/no or one number — sub-50ms, flat $0.001/call at the REST surface. Privacy-chain facts from Seneschal-operated full nodes — Monero (xmr/height, xmr/mempool, xmr/fee, xmr/fee-estimate, xmr/last-block) and Zcash (zec/height, zec/mempool, zec/last-block, zec/pools) — plus Ethereum lookups (cheapest-flashloan, base-fee). Consult /v1/q for per-question input lists and live chain availability.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsNoPer-question parameter object. cheapest-flashloan takes asset (+ optional chain); base-fee and the privacy-chain questions currently take no params.
questionYesWhich atomic fact to ask. See description for the list. Privacy-chain questions use `xmr/<name>` or `zec/<name>`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / params / description
      Previous value: -"Per-question parameter object. DeFi questions take addr/protocol/window/builder/pct/etc. Privacy-chain questions currently take no params."New value: +"Per-question parameter object. cheapest-flashloan takes asset (+ optional chain); base-fee and the privacy-chain questions currently take no params."
  2. Changed1 schema field changed
    • changedInput schema / properties / question / enum
      Previous value: -[
-  "liquidatable",
-  "at-risk-count",
-  "recent-liquidations",
-  "top-builder",
-  "builder-share",
-  "builder-bid",
-  "block-value",
-  "cheapest-flashloan",
-  "data-freshness",
-  "address-risk",
-  "base-fee",
-  "proposer-payment",
-  "xmr/height",
-  "xmr/mempool",
-  "xmr/fee",
-  "xmr/fee-estimate",
-  "xmr/last-block",
-  "zec/height",
-  "zec/mempool",
-  "zec/last-block",
-  "zec/pools"
-]New value: +[
+  "cheapest-flashloan",
+  "base-fee",
+  "xmr/height",
+  "xmr/mempool",
+  "xmr/fee",
+  "xmr/fee-estimate",
+  "xmr/last-block",
+  "zec/height",
+  "zec/mempool",
+  "zec/last-block",
+  "zec/pools"
+]
  3. Changed1 schema field changed
    • changedInput schema / properties / question / enum
      Previous value: -[
-  "liquidatable",
-  "at-risk-count",
-  "recent-liquidations",
-  "top-builder",
-  "builder-share",
-  "builder-bid",
-  "block-value",
-  "cheapest-flashloan",
-  "data-freshness",
-  "address-risk",
-  "base-fee",
-  "proposer-payment",
-  "xmr/height",
-  "xmr/mempool",
-  "xmr/fee",
-  "xmr/fee-estimate",
-  "xmr/last-block",
-  "zec/height",
-  "zec/mempool",
-  "zec/last-block"
-]New value: +[
+  "liquidatable",
+  "at-risk-count",
+  "recent-liquidations",
+  "top-builder",
+  "builder-share",
+  "builder-bid",
+  "block-value",
+  "cheapest-flashloan",
+  "data-freshness",
+  "address-risk",
+  "base-fee",
+  "proposer-payment",
+  "xmr/height",
+  "xmr/mempool",
+  "xmr/fee",
+  "xmr/fee-estimate",
+  "xmr/last-block",
+  "zec/height",
+  "zec/mempool",
+  "zec/last-block",
+  "zec/pools"
+]
  4. Changed1 schema field changed
    • changedInput schema / properties / question / enum
      Previous value: -[
-  "liquidatable",
-  "at-risk-count",
-  "recent-liquidations",
-  "top-builder",
-  "builder-share",
-  "builder-bid",
-  "block-value",
-  "cheapest-flashloan",
-  "data-freshness",
-  "address-risk",
-  "base-fee",
-  "xmr/height",
-  "xmr/mempool",
-  "xmr/fee",
-  "xmr/fee-estimate",
-  "xmr/last-block",
-  "zec/height",
-  "zec/mempool",
-  "zec/last-block"
-]New value: +[
+  "liquidatable",
+  "at-risk-count",
+  "recent-liquidations",
+  "top-builder",
+  "builder-share",
+  "builder-bid",
+  "block-value",
+  "cheapest-flashloan",
+  "data-freshness",
+  "address-risk",
+  "base-fee",
+  "proposer-payment",
+  "xmr/height",
+  "xmr/mempool",
+  "xmr/fee",
+  "xmr/fee-estimate",
+  "xmr/last-block",
+  "zec/height",
+  "zec/mempool",
+  "zec/last-block"
+]
  5. Changed1 schema field changed
    • changedInput schema / properties / question / enum
      Previous value: -[
-  "liquidatable",
-  "at-risk-count",
-  "recent-liquidations",
-  "top-builder",
-  "builder-share",
-  "builder-bid",
-  "block-value",
-  "cheapest-flashloan",
-  "data-freshness",
-  "address-risk",
-  "xmr/height",
-  "xmr/mempool",
-  "xmr/fee",
-  "xmr/fee-estimate",
-  "xmr/last-block",
-  "zec/height",
-  "zec/mempool",
-  "zec/last-block"
-]New value: +[
+  "liquidatable",
+  "at-risk-count",
+  "recent-liquidations",
+  "top-builder",
+  "builder-share",
+  "builder-bid",
+  "block-value",
+  "cheapest-flashloan",
+  "data-freshness",
+  "address-risk",
+  "base-fee",
+  "xmr/height",
+  "xmr/mempool",
+  "xmr/fee",
+  "xmr/fee-estimate",
+  "xmr/last-block",
+  "zec/height",
+  "zec/mempool",
+  "zec/last-block"
+]
  6. Changed1 schema field changed
    • changedInput schema / properties / question / enum
      Previous value: -[
-  "liquidatable",
-  "at-risk-count",
-  "recent-liquidations",
-  "top-builder",
-  "builder-share",
-  "builder-bid",
-  "block-value",
-  "cheapest-flashloan",
-  "data-freshness",
-  "xmr/height",
-  "xmr/mempool",
-  "xmr/fee",
-  "xmr/fee-estimate",
-  "xmr/last-block",
-  "zec/height",
-  "zec/mempool",
-  "zec/last-block"
-]New value: +[
+  "liquidatable",
+  "at-risk-count",
+  "recent-liquidations",
+  "top-builder",
+  "builder-share",
+  "builder-bid",
+  "block-value",
+  "cheapest-flashloan",
+  "data-freshness",
+  "address-risk",
+  "xmr/height",
+  "xmr/mempool",
+  "xmr/fee",
+  "xmr/fee-estimate",
+  "xmr/last-block",
+  "zec/height",
+  "zec/mempool",
+  "zec/last-block"
+]
  7. Changed1 schema field changed
    • changedInput schema / properties / question / enum
      Previous value: -[
-  "liquidatable",
-  "at-risk-count",
-  "recent-liquidations",
-  "top-builder",
-  "builder-share",
-  "builder-bid",
-  "cheapest-flashloan",
-  "data-freshness",
-  "xmr/height",
-  "xmr/mempool",
-  "xmr/fee",
-  "xmr/last-block",
-  "zec/height",
-  "zec/mempool",
-  "zec/last-block"
-]New value: +[
+  "liquidatable",
+  "at-risk-count",
+  "recent-liquidations",
+  "top-builder",
+  "builder-share",
+  "builder-bid",
+  "block-value",
+  "cheapest-flashloan",
+  "data-freshness",
+  "xmr/height",
+  "xmr/mempool",
+  "xmr/fee",
+  "xmr/fee-estimate",
+  "xmr/last-block",
+  "zec/height",
+  "zec/mempool",
+  "zec/last-block"
+]
  8. First observed

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It usefully discloses latency (<50ms), flat pricing ($0.001/call), and data provenance (Seneschal-operated full nodes). It says nothing about authentication requirements, rate limits, failure/availability behavior, or what happens when a chain is offline. Solid cost/perf disclosure, but the operational profile is incomplete.

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?

Three dense, front-loaded sentences with zero filler; the core value proposition (one fact, fast, cheap) leads. The inline enumeration of question IDs partially duplicates the schema enum, costing a little redundancy, but it usefully groups them by chain.

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?

There is no output schema, but "answers ONE yes/no or one number" successfully conveys the return shape, and /v1/q is cited for input detail. Combined with the chain list and pricing, an agent has enough to call it correctly. Auth and error behavior remain unaddressed, but for a simple read-only fact endpoint this is nearly sufficient.

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% and the params object already documents that cheapest-flashloan takes asset (+ optional chain) while other questions take none. The description's contribution is routing the agent to /v1/q for per-question input lists, which is a modest addition. Baseline 3 applies when the schema does the heavy lifting.

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 names a specific verb+resource: atomic single-fact query endpoints across Monero, Zcash, and Ethereum, and enumerates the question families (xmr/height, zec/pools, cheapest-flashloan, base-fee). An agent knows this is a cheap stat lookup, not a scan or subscription tool. It stops short of explicitly differentiating from close siblings like seneschal_zecmon_info or seneschal_flashloan_providers, so it is clear but not fully sibling-aware.

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?

"Designed for tight agent loops" and "Consult /v1/q for per-question input lists and live chain availability" imply the intended use, and sub-50ms/$0.001 hints at when the cost tradeoff is worthwhile. However it never states when to prefer this over seneschal_zecmon_scan or seneschal_flashloan_providers, nor any exclusion conditions. Usage is implied, not directed.

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

All Seneschal Data toolsInspect
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