Seneschal
Server Details
Free, public, read-only REST + Model Context Protocol server exposing real-time and historical DeFi liquidation telemetry for Aave, Morpho, Spark and Compound on Ethereum mainnet, plus block-builder market share data from the operator's own slot-by-slot shadow recorder.
- 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 17 of 18 tools scored. Lowest: 3.2/5.
Each tool has a clearly distinct purpose, from borrower queries to private watch management and builder stats. Even similar tools like list_borrowers and list_at_risk_borrowers are differentiated by parameters and use cases.
All tools follow a consistent snake_case pattern with the 'seneschal_' prefix and verb_noun structure (get_borrower, list_borrowers, create_watch, etc.). No mixing of conventions.
With 18 tools covering borrower monitoring, flash loans, builder stats, premium data, private watch services, and utility endpoints, the count is well-scoped for the server's broad purpose without being excessive.
The tool set covers core CRUD operations for borrowers, private watch create/topup, and various queries. Minor gaps exist (e.g., no delete or manage watch tool, no update for watches), but overall the surface is comprehensive for the advertised domains.
Available Tools
19 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?
No annotations are provided, so the description carries full burden. It discloses caching for 60s but does not mention read-only nature, rate limits, or any side effects. Adequate but could be improved.
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 effectively convey purpose, data content, and caching behavior without waste. Every word earns its place.
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 two parameters and no output schema, the description covers the key aspects: data source (Seneschal shadow recorder), content (builder share and MEV), and caching. It could detail the return shape slightly more, but is largely 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 100%, with both parameters described (limit and window). The description adds minimal extra meaning beyond 'Top-N builders' and does not elaborate on parameter behavior.
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 that the tool returns slot-by-slot ground-truth share of Ethereum block builders and total MEV captured per builder, distinguishing it from sibling tools that deal with flashloans, borrowers, and liquidations.
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 versus alternatives, though the sibling tools cover different topics, so confusion is unlikely. Guidance on usage context is implicit.
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 carries the full burden. It implies a read-only query operation ('curated catalogue'), but does not explicitly state whether modifications occur or if there are side effects. The qualitative liquidity notes suggest safe data retrieval.
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 long with no redundancy. Every part adds value: purpose, contents, use case, and filter options. 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?
The description explains the return values (fee, addresses, liquidity notes, caveats) despite no output schema. Parameter semantics are covered by schema. The tool is a simple query with no nested objects, so the provided context is sufficient for an agent to decide to invoke it.
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?
With 100% schema description coverage, the schema already documents all three parameters (chain, max_fee_bps, multi_asset). The description reiterates filtering but adds no new meaning beyond what the schema provides, warranting a baseline score of 3.
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 identifies the tool as a curated catalogue of Ethereum mainnet flash-loan providers, listing specific providers and details. It distinguishes from sibling tools (e.g., borrower lists, liquidations) by focusing exclusively on provider information.
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 it is 'helpful for searcher agents picking the cheapest viable provider' and mentions filter options, establishing clear usage context. It could be improved by explicitly stating when not to use it, but the purpose is well understood from the sibling set.
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 are provided, so the description must convey behavior. It explains the data scope and input format but lacks details on data freshness, error handling, or authentication requirements.
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, no fluff, and the most important information (purpose and parameter format) is front-loaded.
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 does not explain the return structure (e.g., fields in the snapshot). For a retrieval tool, this is a gap, though the core concept is clear.
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?
With 0% schema coverage, the description adds meaning by specifying the address format (0x-prefixed 20-byte hex) and clarifying it returns state across protocols. This goes beyond the schema 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?
The description clearly states the tool returns the latest known state of an address across multiple protocols (Aave, Morpho, Spark), distinguishing it from siblings like seneschal_get_borrower_history and seneschal_list_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?
Usage context is implied but not explicit. It does not specify when to use this tool versus alternatives (e.g., for history use the sibling tool) or any exclusions.
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 carries the full burden. It explains the return shape and granularity but does not disclose behavioral traits like data ordering, pagination, or potential side effects. It implies read-only behavior but could be more 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?
Two sentences convey the core purpose and an important usage tip with no redundancy. The key action ('Returns a time series...') is front-loaded, making it easy for an agent to quickly grasp.
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 6 parameters (2 required) and no output schema, the description successfully covers the returned fields and the most important parameter (granularity). Defaults and other parameters are adequately handled by the schema. Minor omissions like ordering or data limits are acceptable given the tool's straightforward nature.
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 83%, meeting the high-coverage baseline of 3. The description adds value by explaining granularity options and their intent ('chart-friendly buckets') and clarifies limit as 'Max rows fetched before bucketing'. This goes beyond the schema's basic 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?
Clearly states it returns a time series of specific fields (timestamp, health_factor, collateral_usd, debt_usd) for a given address and protocol. This distinguishes it from sibling tools like seneschal_get_borrower (likely current state) or seneschal_list_borrowers (list view).
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?
Provides guidance on granularity options ('use hour or day for chart-friendly buckets') but does not explicitly compare to sibling tools or state when not to use it. Implicitly suggests it's for historical data but lacks explicit alternatives or exclusions.
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?
No annotations provided; description indicates a read operation returning data but does not mention side effects, caching, or authentication requirements. Adequate but minimal disclosure.
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?
Single sentence, 13 words, front-loaded with verb and resource. No unnecessary information; earns its place.
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 and no output schema, the description adequately informs what data is returned. Could mention output format but not critical for a simple health 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?
No parameters in schema (100% coverage). Description adds meaning by specifying what the tool returns (table sizes and freshness timestamps), which is sufficient for a parameterless tool.
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 specific resources 'table sizes and data-source freshness timestamps' for the Seneschal Data backend, effectively distinguishing it from sibling tools that focus on 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?
The description implies usage for monitoring backend health but provides no explicit when-to-use or alternatives. Lacks guidance on when not to use this tool.
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 borrowersBInspect
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?
With no annotations, the description must cover behavioral traits. It states it's a 'current snapshot' (point-in-time) and 'sorted ascending', but does not disclose pagination, authentication requirements, or response structure. Adequate but not comprehensive.
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 front-loading the main purpose. No extraneous words. Exemplary succinctness.
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 clear purpose, the description lacks details about the output format (e.g., what fields are returned). Without an output schema, the agent has to guess the response structure, which is a significant 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 parameters are already documented. The description adds context for max_hf and min_debt_usd but not for limit or protocol. Baseline 3 is appropriate as the description adds minimal value 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 description clearly states the tool lists at-risk borrowers with health factor below max_hf, sorted ascending, and mentions three protocols. However, it omits 'compound' from the enumeration even though the schema includes it, causing a minor inconsistency.
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 on when to use this tool versus siblings like 'seneschal_list_borrowers'. The description does not mention alternatives or when not to use it, leaving the agent to infer from the name alone.
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 must fully disclose behavioral traits. It mentions the tool operates on a 'snapshot table' and supports pagination, but does not specify whether it is read-only, idempotent, or if it has side effects. The description partially fulfills the transparency burden by explaining the filtering and sorting behavior, but lacks explicit safety characteristics.
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 consists of two dense sentences. The first sentence establishes the purpose and the second adds critical details and usage guidance. Every word serves a purpose; there is no repetition or filler. It is front-loaded and highly 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 complexity (9 parameters, no output schema), the description adequately explains the tool's scope, filtering capabilities, and pagination. It does not describe the response format, but the tool is a list operation and the schema fully documents parameters. The description could be more complete by noting the default limit and max, but those are in the schema. Overall, it provides sufficient context for an agent to use the tool correctly.
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%, giving a baseline of 3. The description adds value beyond the schema by explaining the purpose of the extra parameters relative to the sibling (lower/upper HF bounds, max-debt cap, sort field/direction, offset pagination). This contextualizes the parameters and clarifies their role in the tool's functionality.
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 'generic discovery surface' over the borrower snapshot table, distinguishes it from the sibling `seneschal_list_at_risk_borrowers` by listing additional capabilities (lower/upper HF bounds, max-debt cap, configurable sort, offset pagination), and uses specific verbs like 'walk the catalogue'. The purpose is immediately clear and distinct.
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 'Use this to walk the catalogue without knowing borrower addresses in advance.', providing a clear use case. It contrasts with the sibling tool by noting differences in HF bounds and pagination, but does not explicitly state when not to use it or when to prefer alternatives. However, the guidance is sufficient for typical selection decisions.
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?
Since no annotations are provided, the description carries the full burden. It states 'Free to call,' implying no destructive side effects. It does not mention idempotency or caching, but for a metadata endpoint this is sufficient.
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 states what it returns, the second provides usage guidance. No wasted words, front-loaded with essential 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, the description fully explains what the tool returns (list of paywall metadata fields). It also tells the agent what to do next, making it complete for its simple purpose.
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 0 parameters, so schema coverage is 100%. The description adds context about what is returned but no parameter information is needed. Score reflects the baseline for 0-param tools.
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 protocol, network, recipient address, and per-call price for every gated endpoint. This distinguishes it from sibling tools that provide specific data like borrower lists or leaderboards.
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 it is free to call, agents should consult once to budget a paid session, then make the direct HTTP request with a payment signature. This provides clear when-to-use and what to do after.
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?
No annotations provided, so the description carries the full burden. It discloses important behavioral traits: prepaid credit meter, HMAC-signed webhooks, low_credit warning, and encryption of view keys. It does not mention rate limits or auth requirements beyond the paywall, but overall is fairly 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 paragraph that packs substantial information without being overly verbose. It could be structured into bullet points for clarity, but it is efficient and front-loaded with the key purpose.
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 is complex (paywall, credit meter, encryption), and the description covers many aspects. However, it lacks explicit detail on the return value of the create call (e.g., what the immediate response is, whether it returns a watch ID). The webhook behavior is described, but the synchronous response is not clarified.
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%, but the description adds significant value beyond the schema: address formats for Monero and Zcash, view key formats, webhook URL restrictions, and birthday height defaults. This goes beyond the schema's minimal 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?
The description clearly states the verb ('subscribe') and resource ('Monero or Zcash address to view-key-based payment monitoring'), distinguishing the tool's core function. However, it does not explicitly differentiate from sibling tools like seneschal_private_watch_info or seneschal_private_watch_topup, so a slight deduction.
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 about payment (x402 paywall, credit meter) and topup alternatives, but lacks explicit guidance on when to use this tool vs. alternatives (e.g., when not to use it). The information is present but not structured as usage guidelines.
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 mnemonic transits the server (no logging/persistence) and that network observers could see bytes, plus notes UFVK is read-only. However, does not mention any authentication requirements or error handling 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?
Three sentences, front-loaded with action, no unnecessary words, and effectively combines purpose, warnings, and alternatives.
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?
Covers purpose, usage, security, and behavior. Lacks explicit mention of output format or what happens on invalid input, but is sufficient given no output schema and simple return value.
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 the description adds security context for the 'phrase' parameter and future support for Monero, enhancing understanding beyond raw schema 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?
The description clearly states it derives a UFVK from a BIP-39 mnemonic using a specific CLI, distinguishing it from sibling tools that focus on watching or top-ups.
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 mentions free usage, rate limit (6/minute/IP), security trade-offs, and recommends offline derivation as a safer alternative, providing clear when-to-use and 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_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?
With no annotations, the description carries full burden and discloses that the view key never touches SQLite and is processed in memory only, plus pricing information.
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?
Three sentences, each valuable: purpose, privacy guarantee, usage and pricing. No redundancy, front-loaded with core 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?
Despite no output schema or annotations, the description covers privacy, pricing, default behaviors, and key parameter nuances, making it largely complete for effective 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 coverage is 100% (baseline 3). The description adds key details like view key format, default for includeNotes, and auto-detection for birthdayHeight, exceeding 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 returns spendable and spent notes for a view key without setting up a watch, distinguishing it from sibling watch-related tools.
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,' providing clear context, though it does not mention when not to use it or list alternatives.
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 provided, so description must cover behavioral traits. It states 'Free to call' suggesting no cost, but does not disclose rate limits, authentication needs, or side effects. The read-only nature is implied but not 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?
Two concise sentences. First sentence clearly states purpose, second adds cost note. No 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?
For a parameter-less info tool with no output schema, the description fully covers what is returned (price, chains, health, security notes). No critical missing 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?
Input schema has zero parameters with 100% coverage. No parameter explanation needed; description adds nothing beyond schema but baseline is 4 due to no parameters.
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 returns specific metadata (price, chains, health, security notes) for the view-key payment-monitoring service. It distinguishes from sibling tools like seneschal_private_watch_create (creation) and seneschal_private_watch_historical (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?
The description mentions 'Free to call' but does not explicitly state when to use this tool versus alternatives. It implies use for retrieving service metadata but lacks explicit when-not or alternative 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_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 are provided, so the description carries full burden. It discloses that the tool does not settle payment itself, returns a URL, and describes the three tiers with costs and idle days. Could mention error scenarios or side effects, but overall 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 two sentences, front-loaded with purpose, and contains no wasted words. 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?
No output schema, but description explains the return value (a URL). It covers tiers, costs, and links to sibling tools (watchId and watchToken from create). Could mention error handling, but adequate for a top-up 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 100% (all parameters have descriptions). The description adds context about tier costs and idle days, which complements the schema's enum 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 states 'Add prepaid credit to an existing Private Watch', which is a specific verb+resource. It clearly distinguishes from sibling tools like seneschal_private_watch_create (creates a watch) and seneschal_private_watch_info (retrieves info).
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 explicitly says 'This tool returns the URL the agent should POST to with its x402 client; it does NOT settle payment itself', providing clear guidance on how to use the tool and its limitation. It does not explicitly mention when not to use it, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
seneschal_private_watch_topup_cryptoTop up an existing watch by paying in Monero or Zcash (FREE to quote)AInspect
Fund a Private Watch by paying in XMR or ZEC instead of USDC. Returns the FREE endpoint to call: POST /v1/private/topup-crypto issues a QUOTE — a receiving address, the exact coin amount to send (Monero: the amount carries a unique invoice tag; Zcash: a memo token), and a USD rate locked for a short window. Send the payment, then poll GET /v1/private/topup-crypto/{quoteId} (header x-watch-token) until status=settled. We detect the payment with the same view-key scanner the product sells and never hold a spend key. No x402, no API key — you pay in coin.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | Yes | Which privacy coin you will pay in. | |
| watchId | Yes | The watchId returned from seneschal_private_watch_create. | |
| watchToken | Yes | The watchToken returned from seneschal_private_watch_create. | |
| amountUsdCents | Yes | Credit to buy, in US cents (e.g. 500 = $5.00). Min/max enforced server-side; see seneschal_private_watch_info -> crypto_topup. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the quote generation, payment detection method, and security assurances (no spend key, no API key). Missing explicit mention of write nature, but 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?
Three sentences with good front-loading. Some details (like polling endpoint) could be trimmed, but overall efficient and well-organized.
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 fully covers the return value (quote with address, amount, rate) and subsequent steps (polling). No missing information for an agent to use the tool correctly.
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?
All 4 parameters are documented in schema (100% coverage). The description adds value by explaining the use of watchId/watchToken from creation, the meaning of amountUsdCents, and details about unique invoice tag for Monero and memo token for Zcash.
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 funds a Private Watch by paying in Monero or Zcash, distinguishing it from the sibling seneschal_private_watch_topup (likely USDC). The verb 'fund' and resource 'Private Watch' are specific.
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 explains when to use (pay with XMR/ZEC instead of USDC) and provides a clear step-by-step flow (quote, send, poll). However, it does not explicitly state when not to use or contrast with alternatives.
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?
No annotations provided, so description carries full burden. Discloses sub-50ms latency, flat pricing, data sources (SQLite + shadow-blocks, full nodes). Does not mention read-only nature or error behavior, but adequate given simplicity.
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 front-loaded with key features (atomic, fast, cheap) and well-structured. While it repeats enum values from schema, the list is helpful for quick reference. No wasted sentences.
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 high schema coverage and no output schema, description explains return type (yes/no or number), data sources, and where to get details (/v1/q). Sufficiently complete for an atomic fact 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 covers both parameters (100% coverage). Description adds value by explaining parameter patterns per question family (e.g., DeFi takes addr/protocol), which is not in schema. Baseline 3 exceeded.
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 provides 'atomic single-fact endpoints' answering one yes/no or number, listing two families (DeFi, privacy-chain). Distinguishes from siblings, which appear to be for more complex or bulk 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?
States it's for 'tight agent loops' and 'consult /v1/q for per-question input lists,' implying simple, fast queries. Lacks explicit when-not-to-use or alternatives, but context is clear.
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 provided, so description carries burden. It explains data content, outcome categories, and sorting order, but lacks details on read-only nature, pagination, or performance. Adequate but not extensive.
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, no fluff. Front-loaded with purpose and key details. Every sentence earns its place.
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 three optional parameters, no output schema, and several siblings, the description covers data type, sorting, and outcome categories. Could mention default limit or protocol filtering but schema handles that. Adequately 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 100%, so baseline is 3. Description adds value by explaining the outcome classification in the data, which is not in parameter descriptions. This enhances 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?
Description clearly states it lists recent liquidations, distinguishes between outcomes, and specifies sorting. It is specific and distinguishes from sibling tools like list_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?
No explicit when-to-use or alternatives, but the context of liquidations and outcomes implies usage for tracking liquidation outcomes. Sibling list is present but no comparative guidance.
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 carries the full burden. It lists return data but does not disclose behavioral traits like data freshness, caching, or whether it queries live data. Being a read-only snapshot is implied but not 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 sentence that efficiently conveys the tool's purpose and output. While it is a bit long due to listing many items, it remains clear and front-loaded with the key idea 'Aggregate snapshot.'
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 zero parameters and no output schema, the description is remarkably complete. It enumerates all the data components needed to render a dashboard, leaving no ambiguity about what the tool returns. The sibling tools cover specific sub-queries, making this complete for its intended 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?
The input schema has zero parameters, so the description doesn't need to explain parameters. It adds value by detailing the exact metrics returned (e.g., total positions, debt under watch, HF histogram), which compensates for the lack of output 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 provides an 'Aggregate snapshot' for the public stats dashboard, listing specific data points. It distinguishes itself from sibling tools like seneschal_list_borrowers or seneschal_get_borrower by being a one-call overview.
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 'One call returns everything needed to render the dashboard,' indicating when to use it. It implies that for specific details (e.g., individual borrower info) sibling tools are appropriate, though not stated explicitly.
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!