LiquiLens — the Failure Radar
Server Details
Bank and lender failure early warning, with a validated record across India, the US and Europe.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- beepboop2025/liquilens-mcp
- GitHub Stars
- 0
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 3.6/5 across 10 of 10 tools scored. Lowest: 2.3/5.
Each tool targets a distinct purpose: evidence_* tools provide historical backtests per region or institution, failure_radar_* tools offer live data, and the remaining tools handle regulatory actions, registry search, and verification. There is no functional overlap.
Tool names follow two main patterns (evidence_*, failure_radar_*) but also include verb-first names like universe_search and verify_published_record, mixing conventions. While still readable, the inconsistency reduces predictability.
With 10 tools, the server covers a broad domain without being overwhelming. Each tool serves a clear role, from historical replay to live radar, regulatory data, and verification.
The tool surface covers historical backtests for multiple regions, live radar for India, regulatory actions, registry search, and verification. Minor gaps include lack of live radar for US/EU, but the core use case is well-served.
Available Tools
10 toolsevidence_europeBInspect
Seven named European case files (Credit Suisse, Banco Popular, Northern Rock, Banco Espirito Santo failed; Deutsche Bank, Monte dei Paschi stressed survivors; UBS control) replayed point-in-time through the UNRECALIBRATED Indian lenses, every figure independently audited against primary filings. Case studies with citations — never quote a European recall percentage, there deliberately isn't one. Pass slug for one full case file with the per-quarter table.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | No | optional, e.g. 'credit-suisse' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that figures are independently audited and that there is no European recall percentage, but does not explain the implications of 'replayed through UNRECALIBRATED Indian lenses' or what the tool does beyond providing case files. Annotations are absent, so description carries full transparency burden but leaves 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?
The description is verbose and runs multiple ideas together without clear structure. It includes warnings, process details, and output hints in a single block, making it harder to parse quickly. Could be split into shorter sentences or bullet points.
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 mentions a 'per-quarter table' and 'case files' but does not specify the exact structure or fields returned. For a simple retrieval tool with 7 cases, this is minimally adequate but not fully 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?
The single parameter 'slug' has full schema coverage (100%). The description adds value by explaining that passing a slug retrieves one full case file with a per-quarter table, and gives an example ('credit-suisse'). This goes beyond the schema's basic description.
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 identifies the tool as providing seven named European case files audited against primary filings, distinguishing it from siblings like evidence_us or evidence_india by its European focus. However, the description is dense and could be more straightforward.
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?
Implicitly indicates use for European case files and warns against quoting a European recall percentage, but lacks explicit when-to-use or when-not-to-use guidance vs. other evidence tools. No alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evidence_indiaAInspect
The Indian crisis record: 48 institutions replayed point-in-time from vetted public filings across two decades — verdicts, lead times, the misses and false alarms included, with uncertainty intervals and the rigor artifacts.
| 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 the description bears full burden. It describes content (verdicts, lead times, uncertainty intervals) but does not disclose safety traits, side effects, or authorization needs.
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 a single sentence that packs relevant details, but its dense phrasing may reduce clarity. It is concise yet somewhat overwrought.
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 covers the tool's purpose and returned content adequately. Missing context on how to interpret results or any prerequisites.
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, so no parameter info needed. Baseline 4 applies as description adds no conflicting information, though it also does not explain why no parameters are needed.
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 the Indian crisis record with specific details like 48 institutions point-in-time from vetted filings, distinguishing it from sibling tools (e.g., evidence_europe, evidence_us) by focusing on India.
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 vs alternatives. The name and description imply use for Indian context, but lacking direct comparisons or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evidence_institutionCInspect
One Indian institution's full crisis replay by slug: scored trajectory, sourced quarterly dossier rows, first-alert bookkeeping, verdict line.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | e.g. 'dhfl', 'global-trust-bank' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lists output components but does not disclose behavioral traits such as read-only status, potential destructive effects, or authentication needs.
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?
A single sentence with dense jargon; while concise, the structure is front-loaded but may be hard to parse due to multiple compound terms.
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 single parameter and no output schema, the description provides a reasonable overview of return content, but lacks details on pagination, error handling, or data sources.
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 one parameter 'slug' having examples; description does not add additional meaning beyond the schema, meeting baseline.
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 a full crisis replay for a single Indian institution by slug, and lists components like scored trajectory and verdict line. It distinguishes from siblings like evidence_india by being institution-specific, though not explicitly.
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 use when needing a detailed crisis replay for an Indian institution, but gives no guidance on when not to use or alternatives among siblings like failure_radar_institution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evidence_marketsAInspect
The validation record per market, one headline each: India (48-institution backtest), United States (550-failure industry-wide watchlist backtest), Europe (named audited case files, deliberately no cohort claim). Start here when asked 'is this thing validated'.
| 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 describes the content (validation records per market) but omits behavioral traits like idempotency, data freshness, or response size.
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, front-loaded with the core purpose and key examples. No wasted words, each 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 no output schema and zero parameters, the description explains the tool's purpose and content well. However, without describing the return format or structure, an agent might not know what to expect beyond 'headlines'.
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, so the baseline is 4. The description adds value by explaining the context of each market's validation claim, but parameter semantics are not an issue.
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 provides validation records per market, with specific examples (India, US, Europe), and distinguishes itself from sibling tools like evidence_india or evidence_us by being the top-level entry point.
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 'Start here when asked is this thing validated', providing a clear usage context. However, it doesn't mention when to prefer siblings for specific markets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
evidence_usCInspect
The US bank record: every FDIC-insured bank scored quarterly from free call-report data; 550 receivership failures since 2008, recall 73.1% at a 21.7-month median lead, AUC 0.853 — plus marquee replays (SVB, Signature, First Republic, the two 2026 catches) INCLUDING the honest fraud miss, and the named recent misses: seven for 2023-2026, five fraud plus the two July 2026 microbank misses (Kentland Federal S&L, Small Business Bank) published the week they failed. The 2026 scoreboard reads 2 of 4 flagged a year early. The flag is a budgeted watchlist (top decile per quarter), not an institution-level verdict; quote the budget with the recall, and quote misses next to hits.
| Name | Required | Description | Default |
|---|---|---|---|
| include_trajectories | No | include per-quarter score series (large); default false |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It mentions the output is a 'budgeted watchlist' and 'not an institution-level verdict', but omits critical behaviors like data recency, rate limits, or what triggers scoring updates.
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 excessively long and rambling, with irrelevant performance metrics (recall 73.1%, AUC 0.853) and obscure phrases ('honest fraud miss'). Not structured for efficient parsing.
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 verbosity, the description does not explain the tool's return format or how to interpret results. No output schema exists, so the description should clarify, but it only alludes to a 'flag' and 'budget'.
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% for the single boolean parameter. The description adds no further meaning beyond the schema's 'include per-quarter score series (large); default false'.
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 hints that the tool provides US bank failure scoring and watchlist data, but lacks a clear action verb (e.g., 'get', 'list'). The marketing-style language ('marquee replays', 'honest fraud miss') obscures the core functionality.
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 over siblings like evidence_europe or evidence_india. The geographic scope is implied by the name and first line, but no comparison or selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
failure_radar_boardBInspect
The live Failure Radar board: every Indian institution with a fresh vetted dossier (banks, SFBs, co-op banks, NBFCs, MFIs, HFCs), each with a corpus-calibrated failure PD term structure (12/24/36 months), disclosure score, RBI action-zone status, funding-fragility index, market distance-to-default for listed names, and a watchlist tier under a PUBLISHED rule. Screens, not ratings.
| 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, and the description does not disclose behavioral traits like read-only, destructive, or rate limits. The word 'live' implies real-time data but does not clarify safety or side effects.
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 detailed but somewhat lengthy. It lists many metrics but could be more concise by front-loading the core purpose (e.g., 'View the live Failure Radar board...'). Every sentence adds information, but structure could be improved.
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 covers what the tool returns: types of institutions and specific metrics. It lacks details on how to interpret the data or potential caveats, but is sufficiently complete for a display 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?
The input schema has no parameters, so schema coverage is 100% vacuously. The description adds no parameter details, which is appropriate given zero parameters. Baseline of 4 applies.
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 live board showing Indian institutions with specific metrics like failure PD term structure and watchlist tier. It differentiates by saying 'Screens, not ratings,' but lacks an explicit action verb like 'view' or 'retrieve'.
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 guidance on when to use this tool versus siblings such as 'failure_radar_institution' or 'evidence_india'. The description does not mention alternatives or exclusions, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
failure_radar_institutionAInspect
Full radar dossier for one institution by slug: per-quarter score and PD trajectory with drivers, RBI PCA/SAF headroom history, funding read, forensic screen evidence, market reading. Use failure_radar_board first to discover slugs.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | institution slug, e.g. 'esaf-sfb' |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While no annotations are provided, the description implies a read-only query operation. It does not explicitly state no side effects or auth requirements, but the nature of a 'dossier' makes it evident. Could be improved by stating it's a data retrieval tool.
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 redundant information. First sentence lists the output components, second sentence provides usage guidance. 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 a single parameter and no output schema, the description adequately explains what the tool returns and how to use it. It directs to sibling for prerequisite step. The lack of output structure description is acceptable without an output schema.
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 a clear description of 'slug'. The description adds value by providing an example ('esaf-sfb') and linking to the sibling tool for slug discovery, which goes beyond the schema alone.
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 'Full radar dossier for one institution by slug' and enumerates specific contents (score, PD trajectory, drivers, etc.). It also distinguishes from sibling failure_radar_board by noting that board is used to discover slugs.
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 instructs the agent to 'Use failure_radar_board first to discover slugs', providing clear when-to-use and alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rbi_supervisory_tapeAInspect
Latest RBI enforcement and supervisory actions (penalties, licence cancellations, directions), scraped from rbi.org.in press releases; every item carries the RBI's own URL.
| 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 of behavioral disclosure. It adds that the data is scraped from press releases and includes URLs, but does not disclose update frequency, potential staleness, rate limits, or whether the tool is a read-only snapshot. The behavioral transparency is minimal beyond the basic content description.
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 conveys the key information without unnecessary words. It is front-loaded with the tool's purpose. Could be slightly improved by separating the URL note, but overall 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 and no output schema, the description adequately explains what the tool returns: latest RBI actions with URLs. However, it lacks details on result format, number of items, or whether pagination is supported. For a simple list tool, it is mostly 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?
The input schema has zero parameters, so the description does not need to add parameter information. According to the rubric, baseline is 4 for 0-parameter tools. The description does not repeat any schema fields since there are none.
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 provides the latest RBI enforcement and supervisory actions (penalties, licence cancellations, directions) scraped from official press releases, with each item linking back to the RBI's own URL. The verb is implicit (retrieve/access) and the resource is well-defined, distinguishing it from sibling evidence tools that cover different jurisdictions.
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 when-not-to-use guidance. The description implies it is for retrieving RBI-specific regulatory actions, but does not mention alternatives like 'evidence_india' or conditions under which it should be preferred. Usage is implied by the tool name and content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
universe_searchAInspect
Search the RBI's official registered-NBFC registry (9,000+ entries) by name or CIN, with optional classification (e.g. MFI, HFC) and Scale Based Regulation layer (Upper/Middle/Base) filters. Public record, served verbatim.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | name or CIN substring | |
| layer | No | ||
| limit | No | ||
| classification | No |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'Public record, served verbatim' indicating non-destructive read behavior, but lacks details on authentication, rate limits, or response handling. Since no annotations are provided, description carries full burden and is adequate but not rich.
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 that efficiently conveys purpose and key features without extraneous information. Every piece of 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?
Adequate for a simple search tool with no output schema, but missing details on pagination, error handling, and the exact behavior of the 'limit' parameter. Slightly incomplete given the number of parameters and sibling tools.
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?
Adds meaning to three parameters (q, classification, layer) with examples and filter options, compensating for low schema coverage (25%). Does not describe the 'limit' parameter, but the core parameters are well-explained.
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 specifies the tool searches the RBI's NBFC registry by name/CIN with optional classification and layer filters, distinguishing it from siblings by naming the exact registry and its public nature.
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?
Implied usage for searching NBFC records, but no explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_published_recordAInspect
Independently verify the as-published record: the hash-chained point-in-time ledger commitments (and signatures/anchors where enabled) for a stream, server-side. Reports the verifier's verdict verbatim, even when unflattering — that is the point.
| Name | Required | Description | Default |
|---|---|---|---|
| stream | No | default 'mfi_watchlist' |
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 that the tool reports the verifier's verdict verbatim, even if unfavorable, and mentions the hash-chained nature. This is good transparency, though it could elaborate on error behavior or access 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?
The description is two sentences with zero fluff. The first sentence defines the core action and technical detail; the second emphasizes the honest reporting. 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?
For a tool with one optional parameter, no output schema, and no annotations, the description provides essential context on what is verified and how the result is reported. It could specify the output format or error handling, but overall it is adequate.
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% (one parameter with description). The description adds minimal extra meaning beyond the schema—it refers to 'a stream' but the parameter is already named 'stream' with a default. Baseline score of 3 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 tool's action ('verify the as-published record') and specifies the technical details (hash-chained ledger commitments, signatures/anchors). It uses specific verb 'verify' and resource 'published record', distinguishing it from sibling tools like evidence_* and failure_radar_*.
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 verification of published records but does not explicitly state when to use it versus alternatives or provide exclusion criteria. No guidance on prerequisites or when not to use it.
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!