Seneschal Data
Server Details
Monero/Zcash payment webhooks + DeFi liquidation & Ethereum builder data over MCP. Free tier; x402.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 18 of 18 tools scored. Lowest: 3.5/5.
Most tools have clearly distinct purposes, but there is some overlap between `seneschal_list_borrowers` and `seneschal_list_at_risk_borrowers` (one is a superset), and between `seneschal_builder_leaderboard` and `seneschal_premium_builder_stats` (both about builders but with different outputs). These could cause minor confusion for an agent.
All tools follow the `seneschal_` prefix with snake_case naming. Verbs like `get_`, `list_`, `create_`, `derive_` are used consistently across similar operations. The pattern is predictable, making it easy for an agent to infer tool purpose from the name.
18 tools is well-scoped for a server that offers data on DeFi, builder analytics, and private payment monitoring. Each tool covers a distinct aspect of the backend, and the count is neither too sparse nor overwhelming for the variety of services provided.
The tool surface covers the main data offerings: borrower states, liquidations, builder stats, flashloans, private watch management, and system health. Minor gaps exist, such as no tool for querying a specific builder's stats beyond aggregated views, but the overall coverage is nearly complete.
Available Tools
18 toolsseneschal_builder_leaderboardBuilder leaderboardAInspect
Slot-by-slot ground-truth share of Ethereum mainnet block builders observed by Seneschal's shadow recorder, with total MEV captured per builder in the window. Cached for 60s.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Top-N builders to return. Default 20. | |
| window | No | Lookback window. Default 24h. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes that data is 'cached for 60s', a useful behavioral trait. However, no annotations are provided, so it does not disclose other traits like read-only nature, authentication requirements, or error handling, leaving gaps in transparency.
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 two sentences, front-loading the core purpose and adding a crucial caching detail. Every word serves a purpose, with no redundancy or unnecessary elaboration.
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?
While the description explains what data is returned (share, MEV, caching), it does not mention the available parameters (limit, window), ordering, or output format. Since parameters are fully defined in the schema, the description is minimally complete but lacks additional context for optimal use.
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?
Schema description coverage is 100%, with clear descriptions for limit and window in the input schema. The tool description adds no parameter-specific meaning beyond the schema, so it meets the baseline but does not exceed it.
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 the tool returns slot-by-slot ground-truth share of Ethereum mainnet block builders and total MEV captured per builder. It is specific about the resource (builders), metric, and source (Seneschal's shadow recorder), distinguishing it from siblings like seneschal_premium_builder_stats which likely offers different statistics.
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?
No explicit guidance is given on when to use this tool versus alternatives. Sibling tools such as seneschal_premium_builder_stats and seneschal_stats_overview exist, but the description does not differentiate their use cases or provide selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_flashloan_providersFlash loan provider catalogueAInspect
Curated catalogue of Ethereum mainnet flash-loan providers (Aave V3, Balancer V2, Morpho Blue, Uniswap V3, FlashBank) with current fee in basis points, contract addresses, qualitative liquidity notes, and per-provider caveats. Helpful for searcher agents picking the cheapest viable provider for a liquidation or arbitrage strategy. The catalogue is editorially open: filter by chain, max fee, or multi-asset support.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | Chain key, default "ethereum". Currently only ethereum is catalogued. | |
| max_fee_bps | No | Drop providers whose flat fee exceeds this in basis points (1 bp = 0.01%). | |
| multi_asset | No | If true, only return providers that support borrowing multiple assets in a single flash loan. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It describes the catalogue as 'curated' and 'editorially open,' implying a human-maintained list with potential staleness. It does not disclose update frequency, data source reliability, or any destructive actions (though none are expected). The description is adequate but lacks detail on freshness and whether the data is real-time.
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 two sentences: the first clearly states the tool's content, and the second provides usage guidance. It is front-loaded with purpose and reasonably concise. Minor improvement could be structuring as a bullet list for readability.
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?
The tool has no output schema, so the description should explain the return format. It lists fields (fee, address, liquidity notes, caveats) but does not specify whether the output is a list, sorted, or always returns all providers. It gives a good high-level idea but lacks structural details about the response.
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?
Schema coverage is 100%, so the baseline is 3. The description reiterates the parameters with slight elaboration (e.g., '1 bp = 0.01%' for max_fee_bps), but the schema descriptions are already clear and comprehensive. The description adds minimal extra meaning beyond what the schema provides.
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 it is a curated catalogue of flash-loan providers with specific details (fees, addresses, liquidity notes, caveats). It distinguishes itself from sibling tools (e.g., borrower-related tools) by focusing exclusively on flash-loan providers for liquidation and arbitrage strategies.
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 description explicitly says it is helpful for searcher agents picking the cheapest viable provider for liquidation or arbitrage, providing clear context. It also mentions filterable attributes (chain, max fee, multi-asset support), guiding usage. However, it does not explicitly state when not to use it or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_get_borrowerGet borrower snapshotAInspect
Returns the latest known state of address across every protocol where we have data (Aave, Morpho, Spark). Pass the EOA / contract address as a 0x-prefixed 20-byte hex string.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It indicates the tool returns data (read operation) but does not disclose whether it fetches on-chain data or uses cached state, or any authentication or rate limits. Adequate but not detailed.
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?
Two sentences: first covers purpose and scope, second covers parameter format. No unnecessary words, front-loaded with key information.
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 no output schema or annotations, description covers what it returns and how to call it. However, it lacks details about the return format, potential errors, or limitations (e.g., only works for addresses present in protocols). Adequate for a single-parameter tool but could be more complete.
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?
Schema coverage is 0%, but description fully explains the parameter: 'Pass the EOA / contract address as a 0x-prefixed 20-byte hex string.' This adds concrete format guidance beyond the schema's pattern.
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?
Description clearly states verb (Returns) and resource (latest known state of address across protocols). It distinguishes from sibling seneschal_get_borrower_history by specifying 'latest', implying snapshot over history.
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?
Description implies use for current state but does not explicitly mention when to use this tool versus alternatives like seneschal_get_borrower_history or seneschal_health. No guidance on exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_get_borrower_historyGet borrower historyAInspect
Returns a time series of (timestamp, health_factor, collateral_usd, debt_usd) observations for address on protocol. Granularity defaults to raw observations; use hour or day for chart-friendly buckets.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows fetched from history table before bucketing. | |
| address | Yes | ||
| protocol | Yes | Only aave and morpho have history tables. | |
| since_ms | No | Unix epoch ms. Defaults to now − 7d. | |
| until_ms | No | Unix epoch ms. Defaults to now. | |
| granularity | No | Bucket size; default raw. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the return structure but does not mention behavioral aspects like rate limits, data freshness, or whether the history includes all events. The description says 'defaults to raw observations' but does not explain what raw entails.
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 two sentences, front-loads the purpose, and contains no unnecessary words.
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 no output schema, the description explains return structure and key parameters. It lacks guidance on selecting among siblings but is otherwise complete for a historical data retrieval tool.
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?
Schema coverage is 83%, so baseline is 3. The description adds value by listing the return fields (timestamp, health_factor, etc.) not in schema, and clarifies granularity usage. However, it does not explain the 'limit' parameter or time range defaults beyond schema.
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 it returns a time series of specific fields (health_factor, collateral_usd, debt_usd) for an address on a protocol. It distinguishes from siblings like 'seneschal_get_borrower' by implying historical vs snapshot, but does not explicitly differentiate.
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 description suggests using 'hour' or 'day' for chart-friendly buckets, implying raw is for detailed analysis. However, it does not specify when to use this tool versus sibling tools like 'seneschal_get_borrower' or 'seneschal_health'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_healthService healthAInspect
Returns table sizes and data-source freshness timestamps for the Seneschal Data backend.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It implies a read-only operation by stating it returns data, which is sufficient for a simple health check, though it doesn't explicitly mention safety or idempotency. However, given the simplicity, it is adequately transparent.
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 a single sentence that is front-loaded with the key action ('Returns') and uses no unnecessary words, making it highly concise and efficient.
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 tool has no parameters, no output schema, and a straightforward purpose, the description fully covers what the agent needs to know: what information is returned and for which backend.
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 tool has no parameters, so the description does not need to add parameter meaning. Baseline score of 4 is appropriate.
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 the verb 'Returns' and the specific resources ('table sizes and data-source freshness timestamps') for the 'Seneschal Data backend', which distinguishes it from sibling tools that focus on borrowers, flashloans, and other functionalities.
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 description implies usage for checking backend health but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_list_at_risk_borrowersList at-risk borrowersAInspect
Current snapshot of borrowers across Aave, Morpho, and Spark whose health factor sits below max_hf, sorted ascending. Use min_debt_usd to ignore dust positions.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows. Default 50, max 500. | |
| max_hf | No | Return only borrowers with health factor strictly less than this. Default: no cap. | |
| protocol | No | Restrict to one protocol; omit for all. | |
| min_debt_usd | No | Ignore positions with debt smaller than this many USD. Default: 0. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear full transparency. It states it's a 'current snapshot' (read-only) and sorted ascending, but fails to mention auth needs, pagination, or the inconsistency that protocol enum includes 'compound' while description lists only three protocols. Basic transparency is provided but with gaps.
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?
Two concise sentences: first states purpose with key parameters, second adds usage hint. No redundancies, front-loaded with core intent. Efficient and well-structured.
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?
With no output schema, the description should specify the return fields (e.g., address, health factor, debt). It only mentions 'borrowers' and 'sorted ascending' but leaves the output structure ambiguous. This is a significant gap for an agent to effectively use the tool's output.
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?
Schema coverage is 100%, so baseline is 3. The description adds minimal value: it reiterates max_hf and min_debt_usd context but does not explain limit or protocol beyond what the schema already describes. No significant enhancement over the input schema.
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 the tool lists borrowers with health factor below a threshold across three protocols, sorted ascending. This is a specific verb+resource+condition, and it distinguishes from siblings like seneschal_list_borrowers which likely lacks the health factor filter.
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 description hints at using min_debt_usd to ignore dust, providing context for parameter use, but does not explicitly state when to use this tool versus alternatives like seneschal_list_borrowers. The sibling tool names imply the distinction, but no direct exclusion or alternative mention is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_list_borrowersList borrowers (generic)AInspect
Generic discovery surface over the borrower snapshot table. Like seneschal_list_at_risk_borrowers but with both lower and upper HF bounds, optional max-debt cap, configurable sort field/direction, and offset-based pagination. Use this to walk the catalogue without knowing borrower addresses in advance.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows per page. Default 50, max 500. | |
| max_hf | No | Exclusive upper bound on health factor. | |
| min_hf | No | Inclusive lower bound on health factor. | |
| offset | No | Pagination offset. Default 0. | |
| sort_by | No | Default 'health_factor'. | |
| protocol | No | Restrict to one protocol; omit for all. | |
| sort_dir | No | Default 'asc'. | |
| max_debt_usd | No | Maximum debt in USD (default unbounded). | |
| min_debt_usd | No | Minimum debt in USD (default 0). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses filtering, sorting, and pagination behavior, which is adequate. However, it does not explicitly state that the tool is read-only, mention required permissions, or clarify data freshness. A more explicit read-only hint would improve transparency.
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 three sentences long, front-loads the core purpose, and contains no redundant information. Every sentence adds value: purpose, comparison with sibling, and use case.
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 9 parameters, full schema coverage, and no output schema, the description covers the tool's functionality well. It explains when to use and what parameters are special. It lacks details on return format or pagination behavior, but the schema covers param-level details. Almost complete for a discovery tool.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds conceptual grouping (e.g., 'both lower and upper HF bounds'), but does not provide significant new meaning beyond what the schema already documents for each parameter.
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 uses a specific verb phrase ('list borrowers') and resource ('borrower snapshot table'), and explicitly distinguishes from the sibling 'seneschal_list_at_risk_borrowers' by listing unique parameters (both HF bounds, max-debt cap, sort options, pagination). This makes the purpose clear and unique.
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 description advises using this tool 'to walk the catalogue without knowing borrower addresses in advance', implying a browsing use case. It contrasts with a sibling tool, but lacks explicit when-not-to-use guidance or a full list of alternatives. The context is clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_paywall_infoPaywall / x402 metadataAInspect
Returns the protocol, network, recipient address, and per-call price for every gated endpoint on this data backend. Free to call. Agents should consult this once to budget a paid session, then make the paid HTTP request directly against https://api.seneschal.space/v1/premium/opportunities with an x402 PAYMENT-SIGNATURE header (see https://docs.x402.org).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool is free to call and returns specific metadata. Does not mention rate limits or error handling, but for a simple info endpoint it is adequate. Could add note about idempotency but not required.
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?
Two sentences, each serving a distinct purpose: first describes the output, second provides usage instructions. No wasted words, front-loaded with the most important information.
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 no parameters, no output schema, and simple nature, the description is complete. It tells the agent what the tool returns, that it's free, and how to proceed after calling it. Includes external documentation link for further details.
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?
No parameters exist (0 params, schema coverage 100%). Baseline set to 4 per guidelines. Description adds value by explaining the tool's purpose and output, which compensates for lack of parameter descriptions.
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?
Description clearly states it returns protocol, network, recipient address, and per-call price for every gated endpoint. Specific verb 'Returns' with defined resource. Distinct from sibling tools which are about builders, borrowers, liquidations, etc.
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?
Explicitly says 'Free to call' and provides a clear action plan: consult once to budget a paid session, then make a direct HTTP request with x402 header. Includes a link to docs. This is high-quality guidance on when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_private_watch_createCreate a Monero/Zcash payment watch (paid via x402 at REST)AInspect
Subscribe a Monero or Zcash address to view-key-based payment monitoring. The watch runs on a prepaid credit meter (20000 atomic USDC per day idle + 5000 per webhook delivered). Creation at the REST surface (POST /v1/private/watch) is paywalled at $0.10 via x402 and seeds the watch with $0.10 of credit. Receiver gets HMAC-signed webhooks plus a 'credit' block on every body; a 'low_credit' warning fires once before the meter expires. Top up via /v1/private/topup, topup-1, or topup-5. View keys are AES-256-GCM encrypted at rest.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Which privacy chain to monitor. | |
| address | Yes | Public address for the chain. Monero: standard 95-char base58. Zcash: u1*, t1*, t3*, zs1*. | |
| viewKey | Yes | Monero: 64-hex private view key. Zcash: UFVK starting with uview1. | |
| webhookUrl | Yes | HTTPS endpoint we POST signed webhooks to. Private RFC1918/localhost addresses are rejected. | |
| birthdayHeight | No | Block height the wallet was created at. Monero: scans forward from this height. Zcash: defaults to NU6 (3_042_000) if unspecified. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the credit meter, x402 paywall, webhook structure (HMAC-signed with credit block), low_credit warning, and view key encryption. This is highly transparent about behavioral traits.
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 front-loaded with the main purpose and each subsequent sentence adds value. It is succinct yet comprehensive, covering credit, paywall, webhooks, and encryption without redundancy.
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 complexity and no output schema, the description covers credit meter, webhooks, encryption, and topup. However, it omits the return format of the creation API itself (e.g., watch ID). This is a minor gap.
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?
Schema coverage is 100%, so baseline is 3. The description adds context for the overall workflow but doesn't significantly enhance param understanding beyond schema. The schema already describes each parameter adequately.
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 uses a specific verb 'Subscribe' and resource 'Monero/Zcash address to view-key-based payment monitoring'. It clearly distinguishes from sibling tools like derive_viewkey, historical, info, topup by being the create variant.
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 description provides context on when to use (to start monitoring) and mentions related topup tools for credit replenishment. It doesn't explicitly state exclusions but covers the payment aspect and encryption, giving good guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_private_watch_derive_viewkeyDerive a Zcash UFVK from a BIP-39 mnemonic (FREE, rate-limited)AInspect
Hands a 12- or 24-word seed phrase to NFPT's orchard-scanner CLI, returns the matching UFVK. FREE but rate-limited to 6/minute/IP. Be loud about the security trade-off: the phrase transits our server (no logging, no persistence) but a network observer between you and us would see the bytes. Offline derivation with the orchard-scanner binary on a trusted host is the safer alternative — see https://docs.seneschal.space/derive-locally. A UFVK is read-only; it cannot spend funds.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Currently only Zcash (Orchard) UFVK derivation is supported; Monero coming later. | |
| phrase | Yes | 12- or 24-word BIP-39 mnemonic. | |
| network | No | Zcash network the wallet belongs to. | mainnet |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the phrase transits the server (no logging) and warns about network observer. Mentions rate limiting (6/minute/IP) and that UFVK is read-only. Slightly missing explicit statement about idempotency, but overall transparent given no annotations.
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?
Well-structured and front-loaded with the action. Around 100 words, no wasted sentences. Could be slightly more concise, but efficient overall.
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 no annotations and no output schema, the description covers purpose, usage, security, and limitations. Does not detail return format, but that is implied. Adequate for the tool's 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?
Schema coverage is 100%, so baseline is 3. Description adds minor context (e.g., chain: future Monero support), but mostly repeats schema descriptions. Does not significantly enhance parameter understanding.
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?
Clearly states that it derives a UFVK from a BIP-39 mnemonic, specifying the verb 'derive' and resource 'UFVK'. Distinguishes from sibling tools by mentioning it's free and rate-limited, and specifically for Zcash.
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?
Explicitly tells when to use (need UFVK from mnemonic) and when not to use (prefer offline derivation for security). Provides an alternative (offline orchard-scanner binary) and a link, guiding the agent to the correct tool choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_private_watch_historicalOne-off historical scan (paid via x402 at REST)AInspect
Return all spendable + spent notes for a view key without setting up a watch. The view key never touches our SQLite — it flows through to NFPT in memory only. Use this when you want to reconcile a wallet at a point in time. Priced at $0.50 / call at the REST surface.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Which privacy chain to scan. | |
| address | Yes | Address whose notes you want. | |
| viewKey | Yes | Monero: 64-hex private view key. Zcash: UFVK starting with uview1. | |
| toHeight | No | Stop scanning at this block height. Defaults to chain tip. | |
| includeNotes | No | Include a per-note breakdown (value/height/tx_hash/spent) in the response. Default false — totals only. | |
| birthdayHeight | No | Skip scanning earlier blocks. Zcash auto-detects when omitted (slower but always correct). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that the view key never touches SQLite and flows to NFPT in memory. Also reveals pricing ($0.50/call). Missing rate limits or error behavior.
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?
Two sentences plus pricing note. Front-loaded with purpose and key distinguishing facts. Every sentence adds value.
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?
Despite no output schema, description explains return contents (totals and optional per-note breakdown). Covers pricing and data handling. Adequate given parameter complexity (6 params, 3 required).
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?
Schema coverage is 100%, so baseline 3. Description does not add significant meaning beyond the schema's parameter descriptions. It mentions pricing but not parameter specifics.
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?
Clearly states the tool returns all spendable and spent notes for a view key without setting up a watch. Distinguishes from siblings by highlighting 'one-off historical scan' and 'no SQLite' persistence.
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?
Explicitly says 'Use this when you want to reconcile a wallet at a point in time.' Implicitly contrasts with continuous watch tools. Could be improved by mentioning alternatives like seneschal_private_watch_create for ongoing monitoring.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_private_watch_infoPrivate watch — service metadataAInspect
Returns the current price, supported chains, NFPT upstream health, and security notes for the view-key payment-monitoring service. Free to call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions 'Free to call' implying no side effects, but does not explicitly state read-only, rate limits, or security implications of 'security notes'. This is adequate but could be more explicit.
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 a single, well-structured sentence that front-loads the most important information (what is returned) and ends with a usage note ('Free to call'). No unnecessary words.
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?
Despite lacking an output schema, the description lists the main output fields (price, chains, health, security notes) sufficiently for a zero-parameter tool. No additional context is needed.
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 tool has zero parameters with 100% schema description coverage (no params to describe). Baseline score of 4 applies as the description does not need to add parameter details.
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 explicitly lists the returned data (price, supported chains, NFPT upstream health, security notes) and identifies the tool as a metadata service for view-key payment-monitoring. This verb+resource specificity distinguishes it from sibling tools like seneschal_private_watch_create or seneschal_private_watch_historical.
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 description states 'Free to call', which indicates a low-cost/no-risk operation. It does not explicitly compare to alternatives, but given the tool's purpose as a read-only metadata endpoint, the context is clear enough for an agent to decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_private_watch_topupTop up an existing watch (paid via x402 at REST)AInspect
Add prepaid credit to an existing Private Watch. Three tiers — $0.10 (default), $1.00, and $5.00 — each settling at the matching REST path (/v1/private/topup, /topup-1, /topup-5). Credit is in atomic USDC ($0.02/day idle, $0.005/call). This tool returns the URL the agent should POST to with its x402 client; it does NOT settle payment itself.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | Top-up size. 10c = $0.10 (≈5 days idle), 1 = $1.00 (≈50 days), 5 = $5.00 (≈250 days). | 10c |
| watchId | Yes | The watchId returned from seneschal_private_watch_create. | |
| watchToken | Yes | The watchToken returned from seneschal_private_watch_create (constant-time compared at the REST surface). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that the tool returns a URL for POST and does not settle payment itself, and provides credit cost and idle time details. However, it does not mention rate limits, authentication requirements, or error handling.
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?
Description is three sentences, concise and front-loaded with the core purpose. No wasted words, but could be slightly more structured (e.g., separate usage note).
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 no output schema and no annotations, the description covers essential aspects: purpose, parameters, behavior (returns URL, no payment settlement), and tier meanings. It lacks guidance on potential errors or prerequisites beyond watch creation.
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?
Schema coverage is 100%, and description adds significant meaning: explains tier values in terms of days idle, and clarifies that watchId and watchToken come from seneschal_private_watch_create. This goes beyond the schema's descriptions.
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?
Description clearly identifies the tool's purpose: 'Add prepaid credit to an existing Private Watch.' It uses specific verbs and resource (top up, Private Watch) and distinguishes from sibling tools like seneschal_private_watch_create.
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?
Description explains the tool is for topping up an existing watch and mentions the tiers. It does not explicitly state when not to use or list alternatives, but the context is clear from the tool name and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_qPenny Oracle: atomic single-fact endpoints (DeFi + privacy chains)AInspect
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. Two families: (1) DeFi facts sourced from our SQLite + shadow-blocks recorder (liquidatable, at-risk-count, recent-liquidations, top-builder, builder-share, builder-bid, cheapest-flashloan, data-freshness); (2) privacy-chain facts sourced from Seneschal-operated full nodes — Monero (xmr/height, xmr/mempool, xmr/fee, xmr/last-block) and Zcash (zec/height, zec/mempool, zec/last-block). Consult /v1/q for per-question input lists and live chain availability.
| Name | Required | Description | Default |
|---|---|---|---|
| params | No | Per-question parameter object. DeFi questions take addr/protocol/window/builder/pct/etc. Privacy-chain questions currently take no params. | |
| question | Yes | Which atomic fact to ask. See description for the list. Privacy-chain questions use `xmr/<name>` or `zec/<name>`. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses sub-50ms latency, flat $0.001 cost, data sources (SQLite+shadow-blocks, full nodes), and lists all questions. No side effects or mutation details are mentioned, but behavior is transparent.
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 information-dense but well-structured into two families. It could be slightly more concise, but every sentence adds value. Front-loading is effective.
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 no output schema and 2 params, the description covers purpose, data sources, cost, latency, and question list. It references /v1/q for additional input details, which is a minor gap but acceptable.
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?
Schema coverage is 100%, and param descriptions exist. The description adds context about per-question parameter variations (DeFi questions take addr/protocol etc., privacy-chain questions take none), enhancing understanding beyond the schema.
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 title and description clearly state this tool provides atomic single-fact endpoints answering yes/no or number questions. It distinguishes from siblings by being generic and covering both DeFi and privacy chains, with an explicit list of question types.
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 description says 'designed for tight agent loops' and advises consulting /v1/q for per-question inputs. It implies usage for quick atomic queries but does not explicitly contrast with siblings or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_recent_liquidationsRecent liquidationsAInspect
Liquidations observed in the recent past, including both ones won by other liquidators (outcome=won_by_other) and ones we ourselves landed (outcome=we_landed). Sorted by timestamp descending.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max rows. Default 50, max 500. | |
| protocol | No | Restrict to one protocol. | |
| since_ms | No | Unix epoch milliseconds. Defaults to now − 24h. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns liquidations with outcome types and sorting order. It does not mention any destructive behavior, auth needs, or rate limits, but for a read-only tool with this purpose, the transparency is adequate.
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 two sentences, front-loaded with the key purpose and outcome details. Every part is informative and there is no redundancy or wasted words.
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?
The tool has no output schema, but the description explains the outcome field and sorting order, providing a good mental model. The limit and since_ms parameters are covered by the schema. Minor omission: could mention the default time range (24h) that is already in since_ms description.
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?
Schema coverage is 100% with all three parameters described. The description adds value by stating 'Sorted by timestamp descending' and explaining the outcome categories, which are not in the schema. This helps the agent understand the data context beyond parameter definitions.
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 specifies 'Liquidations observed in the recent past' with clear outcome categories ('won_by_other', 'we_landed'), and 'Sorted by timestamp descending'. This clearly distinguishes it from sibling tools like seneschal_list_at_risk_borrowers or seneschal_list_borrowers, which deal with different data.
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 description does not explicitly state when to use this tool over alternatives or when not to use it. It implies usage for viewing recent liquidation events, but lacks guidance on context or exclusions, which is a gap given the number of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_stats_overviewPublic stats overviewAInspect
Aggregate snapshot powering the public stats dashboard at stats.seneschal.space: total positions tracked, debt under watch, HF distribution histogram, top-10 at-risk borrowers, 30-day liquidations-per-day series, builder market share for 24h/7d/30d windows, and 10 most recent on-chain liquidations. One call returns everything needed to render the dashboard.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It correctly describes the tool as returning data without side effects, but lacks information on update frequency or caching behavior, which would be helpful for an agent.
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 a single sentence that front-loads the main purpose and lists return components efficiently. It is slightly long but contains no filler, earning a solid 4.
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 no output schema and no parameters, the description fully enumerates all return data fields (positions, debt, histogram, etc.), making it complete for rendering the dashboard without additional context.
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 input schema has no parameters and the description adds value by detailing the return structure (e.g., HF distribution histogram, top-10 borrowers). With 0 parameters, a baseline of 4 is appropriate, and the description compensates well.
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 explicitly states it provides an 'aggregate snapshot powering the public stats dashboard' and lists the specific data points included, distinguishing it from sibling tools that focus on individual pieces like recent liquidations or at-risk borrowers.
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 description implies the tool is for getting a complete dashboard snapshot, but does not explicitly guide when to use sibling tools for specific subsets (e.g., using seneschal_recent_liquidations for only recent liquidations). No when-not-to-use or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!