Skip to main content
Glama

Premium opportunity feed (paid)

seneschal_premium_opportunities

Top at-risk borrowers across Aave + Morpho + Spark, annotated with realised 7d market intel (top liquidators, win rate, our own attempt outcomes) and ranked by expected liquidation value. Behind an x402 paywall: free agents see a paywall stub describing how to pay; paying agents fetch the full feed at https://api.seneschal.space/v1/premium/opportunities. Use seneschal_paywall_info to inspect the price/network/recipient before opening a session.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum opportunities returned (1..500). Defaults to 200.
since_msNoLookback window start (epoch ms). Defaults to now − 7d.
min_debt_usdNoMinimum debt-USD to include. Defaults to 0.
liquidation_bonusNoOverride the assumed liquidation bonus (e.g. 0.05 for 5%). Defaults to 0.06.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses the key behavioral trait: the x402 paywall gating — free agents see a stub, paying agents fetch the full feed from the given URL. It also mentions the included data fields. There is no contradiction with annotations (none exist). It could add failure modes or rate limits but the essential gating behavior is well covered.

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?

The description is two sentences and packs in the purpose, data content, paywall behavior, URL, and a usage pointer. It is efficient and front-loaded, though slightly dense with URLs and enumerated lists. Every sentence serves a purpose, meriting a 4 rather than a 5 due to mild complexity.

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 paywalled read-only feed with 4 parameters and no output schema, the description provides substantial context: what the feed contains, how the paywall works, and where to get payment details. It lacks explicit return-shape or error handling details, but given no output schema, the description does enough to set agent expectations.

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%, with all 4 parameters (limit, since_ms, min_debt_usd, liquidation_bonus) already described in the schema. The description adds minimal extra meaning beyond a subtle reference to the 7d lookback (matching since_ms default). Per the baseline rule, a 3 is appropriate 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.

Purpose5/5

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

The description clearly identifies this as a premium feed of top at-risk borrowers from Aave, Morpho, and Spark, annotated with 7d market intel (liquidators, win rate, attempt outcomes) and ranked by expected liquidation value. It distinguishes itself from siblings like seneschal_list_at_risk_borrowers and seneschal_recent_liquidations by emphasizing the premium/paywalled nature and the ranking/intel content.

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?

It provides explicit guidance to use seneschal_paywall_info before opening a session, which is a clear pre-requisite. It also explains the paywall flow (free vs paying agents), implying this tool is for premium needs, though it does not explicitly compare against alternative free feeds.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Tools are grouped by domain (board, private_watch, zecmon) with clear lifecycle separation, but seneschal_list_at_risk_borrowers and seneschal_list_borrowers overlap heavily, and the USDC vs crypto variants of private_watch_create/topup could be confused without careful reading.

Naming Consistency4/5

Most tools follow a seneschal_<domain>_<action> pattern, but verb/noun order varies (get_borrower vs list_borrowers vs board_list) and outliers like seneschal_health and seneschal_q break the pattern.

Tool Count3/5

At 35 tools, the server is definitely heavy, but it covers multiple distinct domains (DeFi data, privacy-chain monitoring, notice boards, payments), so the count is at the high end of reasonable rather than absurdly bloated.

Completeness4/5

Core workflows are well covered: borrower discovery/analysis, liquidations, private watch lifecycle, Zcash scanning lifecycle, board operations, and checkout invoices. Minor gaps like board deletion or watch cancellation exist but are workaround-able.