Distressed-SMB diligence: bankruptcy, lawsuits, recalls, exclusions, WARN layoffs, liens (sourced).
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.
Average 3.9/5 across 5 of 5 tools scored.
Most tools are distinct, but ch11_feed and ch11_preview both target Chapter 11 filings, with the difference being paid vs. free details. This could cause confusion if descriptions aren't read carefully.
Naming is inconsistent: two tools use 'ch11_' prefix, but the rest mix verb_noun (check_recall_exposure), noun (diligence_brief), and adjective_noun (quick_scan). No consistent pattern.
Five tools is well-scoped for a distress diligence server, covering bankruptcy filings, recalls, and a comprehensive brief without being excessive.
The tool set covers core distress signals (bankruptcy, recalls) and a composite brief. Minor gaps like a standalone lawsuit or WARN search exist but are partly addressed by the diligence_brief.
ch11_feedAInspectFresh CHAPTER 11 FIREHOSE for the restructuring/creditor bar. Returns new business reorganization filings (newest-first) across the major bankruptcy venues, each with the debtor's-counsel firm + attorney, presiding judge, docket number, filing date and a CourtListener link. Args: days (lookback, default 14), court (optional CourtListener court id like deb/nysb/txsb). Public-docket decision-support for counsel; not legal advice, not a solicitation of the estate. [x402: full feed settles $0.50 USDC on Base mainnet, keyless; free header preview included.]
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (default 14, max 60). | |
| court | No | Optional CourtListener court id (deb, nysb, txsb, njb, cacb, flsb…). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses important behavioral traits: returns a paged feed (newest-first), includes a CourtListener link, and notably reveals a payment mechanism (x402: full feed settles $0.50 USDC; free header preview). Also includes a disclaimer about not being legal advice or solicitation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key purpose and return structure, then covers parameters, legal disclaimer, and payment info. Every sentence adds value, though the payment note could be separated for clarity. No wasted words, but slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers what the tool returns (list of filings with specific fields), parameters with defaults and examples, and a behavioral note on payment. It lacks error handling or rate limit info but is otherwise comprehensive for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents both parameters. The description adds value by providing concrete examples of court ids (deb, nysb, txsb, njb, cacb, flsb) and stating the default for 'days' (14). This helps the agent understand valid inputs beyond the schema's 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?
The description clearly states it returns new business reorganization filings with specific details (debtor's counsel, judge, docket number, date, link) and ordering (newest-first). It distinguishes itself from sibling tools like 'preview' or 'diligence_brief' by focusing on a fresh feed of filings.
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 the target audience (restructuring/creditor bar) and a use case (public-docket decision-support), but does not explicitly say when to use or not use this tool versus alternatives like `ch11_preview` or `quick_scan`. Usage is implied rather than guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ch11_previewAInspectFREE preview of the most-recent Chapter 11 business filings — case headers only (name, court, filing date, docket link). The teaser for the restructuring lane.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (default 14). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full burden. It partially discloses behavior: returns only case headers for recent filings. However, it does not explicitly state it is read-only or mention any side effects, rate limits, or data freshness.
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 with no fluff. The first sentence front-loads the core purpose and output, making it immediately scannable.
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's simplicity (single parameter, no output schema), the description adequately lists the returned fields. It omits details like pagination or data limits, but for a preview tool this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'days' parameter already described as a lookback window. The tool description adds no further meaning or usage details for this parameter, meeting the baseline expectation.
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 a free preview of recent Chapter 11 filings with specific fields (case headers, name, court, filing date, docket link). It identifies itself as a 'teaser', setting it apart from sibling tools like ch11_feed which likely offer more detail.
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 for quick initial previews but does not explicitly specify when to use this tool versus siblings (e.g., ch11_feed, diligence_brief). No guidance on prerequisites or limitations is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_recall_exposureAInspectFREE: check a business name against CPSC product-recall records — the held-inventory / recoverable-recall liability line. Returns matched recalls with hazard + units.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Manufacturer/importer/retailer name (required). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It states the tool is free, performs a read-only query (checking records), and returns specific data (hazard + units). It does not mention side effects or authorization needs, but the read-only nature is clear. The description adds value beyond the input schema.
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 purpose, scope, and output without any fluff. Every word is informative, and the structure efficiently front-loads the key action ('check a business name') and result ('returns matched recalls').
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's simplicity (one required parameter, no output schema, no nested objects), the description provides complete context. It explains what the tool does, what it checks (CPSC records), and what it returns (hazard + units). The 'FREE' note adds real-world context. Nothing essential is missing.
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 100% description coverage for the single parameter 'name', which is adequately described as 'Manufacturer/importer/retailer name (required)'. The description's mention of 'business name' adds little beyond the schema. Since schema coverage is high, a baseline 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 checks a business name against CPSC recall records and specifies the output (matched recalls with hazard and units). The verb 'check' and resource 'CPSC product-recall records' are precise, and the 'FREE' indicator adds context. While sibling tool names are given, the description's specificity distinguishes it without needing explicit differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for checking recall exposure but provides no explicit guidance on when to use it versus siblings like 'diligence_brief' or 'quick_scan'. There is no mention of prerequisites, limitations, or alternative tools. The 'FREE:' note offers minor context but not usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
diligence_briefAInspectGenerate a distressed-SMB DILIGENCE BRIEF for an acquisition target. Pass the business name (+ optional US state and domain). Combines REAL public-data signals: lawsuits & bankruptcy dockets (CourtListener/PACER), held-inventory recall exposure (CPSC), federal exclusion/sanctions (OFAC SDN + OIG LEIE), WARN-Act layoffs, and UCC liens where seeded — each with source + date. Returns a structured brief plus risk/opportunity flags with severity. Informational decision-support; verify independently. [x402: full brief settles $0.50 USDC on Base mainnet, keyless; free quick-scan included.]
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Target business legal/trade name (required). | |
| state | No | US state 2-letter code (sharpens WARN/UCC/registration). | |
| domain | No | Target website domain (optional, for the record header). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully discloses behavior: combines public-data signals from specific sources (CourtListener/PACER, CPSC, OFAC, etc.), returns structured brief with risk/opportunity flags, includes a cost model ($0.50 USDC settlement) and a disclaimer to verify independently. This covers key behavioral traits beyond minimal expectations.
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 concise (4 sentences), front-loaded with the core purpose, and efficiently lists data sources in parentheses. Every sentence provides necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (multiple data sources) and absence of output schema or annotations, the description provides a solid overview of returns (brief with flags) and limitations (verify independently). It could further detail the output structure, but it sufficiently covers the tool's purpose and 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?
Input schema has 100% coverage with descriptions, but the description adds meaning: explains that 'state' sharpens WARN/UCC/registration and 'domain' is for the record header. This clarifies the practical impact of each parameter, adding 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 specifies the tool's purpose: 'Generate a distressed-SMB DILIGENCE BRIEF for an acquisition target.' It details the verb (generate), resource (brief), and context (distressed-SMB acquisition). It lists specific data sources (lawsuits, bankruptcy, recalls, sanctions, layoffs, liens) differentiating it from siblings like 'check_recall_exposure' or 'quick_scan'.
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 required inputs ('Pass the business name + optional US state and domain') and implies usage for acquisition due diligence. However, it does not explicitly state when not to use this tool or provide alternatives among siblings. The mention of 'free quick-scan included' hints at a simpler option but lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
quick_scanAInspectFREE quick signal scan for a target business: distress/liability counts + a one-line go/caution/stop verdict, with no per-item detail. The teaser a buyer runs on a listing.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Target business name (required). | |
| state | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses it's free, quick, and returns a summary without per-item detail. However, without annotations, it fails to mention potential side effects, authentication needs, or data limitations. 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 sentences plus a tagline, 34 words, front-loaded with key purpose and output. No fluff, 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?
For a simple tool with no output schema and 2 params, the description provides essential context. However, it omits parameter details (state) and potential limitations. Adequate given the tool's simplicity but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers one parameter (name) with description. The description adds context about the scan's purpose but does not explain the 'state' parameter. With 50% schema coverage, description should compensate more.
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 (scan), resource (target business), and output (distress/liability counts and verdict). The phrase 'teaser a buyer runs' implies it's a preliminary step, differentiating from siblings like diligence_brief which likely provide full detail.
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 as a quick teaser before full diligence, but no explicit when-not-to-use or comparison with siblings. The description provides context but not robust guidelines.
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.
No comments yet. Be the first to start the discussion!