ABC/receivership wind-down asset maps: state notices joined to UCC collateral & secured parties.
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 4.1/5 across 5 of 5 tools scored.
Each tool targets a distinct purpose: feed, search, or map for either ABC or WARN contexts. The descriptions clearly differentiate between the two distress event types and the map functions.
All names use lowercase with underscores, follow a consistent pattern with domain prefixes (abc_, warn_) followed by a descriptive verb_noun or noun_noun combination.
Five tools is well-scoped for the server's purpose of providing distress event feeds and generating asset maps. The count is neither too few nor excessive.
Coverage is good: feeds for both ABC and WARN events, a search for ABC notices, and map functions for both. A minor gap is the lack of a dedicated search for WARN notices, but the feed is available.
abc_asset_mapAInspectBuild the full WIND-DOWN ASSET / COLLATERAL MAP for one ABC/receivership case. Pass the notice link (from abc_distress_feed/abc_find_notices) and/or the assignor entity name. Joins the failing entity to FREE-STATE UCC-encumbered collateral + secured parties (Colorado SOS, live keyless) and the county-recorder real-property lookout, then returns the collateral inventory + buyer actions per role (assignee/liquidator, distressed-asset/IP buyer, creditor). The map the assignee needs to actually run the wind-down — and the map a buyer needs to bid first. Multi-hop parse is hand-verifiable; verify before acting. [x402: full map settles $0.50 USDC on Base mainnet, keyless; free preview included.]
| Name | Required | Description | Default |
|---|---|---|---|
| link | No | Notice page URL (preferred — we parse the assignor + case). | |
| state | No | US state 2-letter code (record header / recorder lookout). | |
| entity | No | Assignor / distressed entity name (use if no link, or to override the parse). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool performs a 'multi-hop parse' that is hand-verifiable, advises to verify before acting, and mentions a payment of $0.50 USDC on Base mainnet. This goes beyond basic read/write hints to include cost and verification 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 information-dense but not verbose. It starts with the purpose, then inputs, process, outputs with roles, a caveat for verification, and finally the payment note. Every sentence serves a clear purpose 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 tool's complexity (3 optional params, no output schema), the description covers what the tool returns (collateral inventory and buyer actions per role) and mentions the payment. It is complete enough for an agent to understand when to call this tool, though it could be slightly more detailed on the output structure.
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%, and the description adds value by explaining that 'link' is preferred for parsing the assignor/case, 'entity' is used to override or when no link is available, and 'state' is for the recorder lookout. These enrich the 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 the tool builds a 'full WIND-DOWN ASSET / COLLATERAL MAP for one ABC/receivership case,' specifying the verb 'build' and resource 'asset/collateral map.' It distinguishes from sibling tools like abc_distress_feed and abc_find_notices, which are about finding notices, and warn_liquidation_map and warn_plant_deaths, which are different in scope.
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 tells agents to pass the notice link from abc_distress_feed/abc_find_notices and/or the assignor entity name. It implies the tool is for building the asset map once a notice is found, but does not explicitly state when not to use it or provide direct alternatives. However, the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
abc_distress_feedAInspectFREE: live feed of state ASSIGNMENT-FOR-BENEFIT-OF-CREDITORS (ABC) and RECEIVERSHIP public legal notices — the wind-down firehose with NO PACER. Each notice: type (receivership/abc/asset-auction/lien-foreclosure), the assignor/distressed entity where parseable, case number, claim/sale date, and link. Beachhead state: WA (a notice-publishing state); FL/NY/DE link-out, CA/TX are dark. Wind-downs move fast — this is the clock.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max notices to return (default 40). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses the tool's read-only nature and real-time behavior, and mentions geographic limitations. However, it does not address pagination, rate limits, or frequency of 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 relatively concise and front-loaded with the core purpose, though includes some promotional language ('FREE'). Every sentence adds context, but could be slightly more streamlined.
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 simple input schema and no output schema, the description adequately explains the content and geographic coverage. It partially describes the output format, making it reasonably complete for a feed 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 schema already covers the single parameter 'limit' with a description. The tool description adds no additional parameter-specific meaning, so 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 it provides a live feed of ABC and receivership public legal notices, specifying the types of notices and what is included. It distinguishes from sibling tools like abc_find_notices by emphasizing its real-time, firehose 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?
The description implies use for monitoring wind-downs in real-time but does not explicitly state when to use this tool versus alternatives like abc_find_notices. It provides geographic context (WA, FL, etc.) but no explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
abc_find_noticesAInspectFREE: keyword-search the wind-down legal-notice archive (e.g. 'receivership', 'assignment for benefit of creditors', 'assignee', a company name). Returns matching notice headers + links you can feed into abc_asset_map.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 15). | |
| keyword | Yes | Search term (required). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavioral traits. It indicates a read operation and mentions 'FREE', but lacks details on rate limits, pagination, 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. Provides examples and links to sibling tool efficiently.
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 search tool with few parameters and no output schema, description covers purpose, examples, and follow-up action. Missing details on empty results or error handling, but sufficient for most cases.
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%, but description adds value with search term examples and output context (headers+links), going beyond schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches a specific archive (wind-down legal notices) with keyword examples, and distinguishes from siblings by noting output can feed into abc_asset_map.
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 examples of when to use (searching for legal terms or company names) and implies a follow-up step, but does not explicitly state when not to use or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
warn_liquidation_mapAInspectBuild the LIQUIDATOR-facing ASSET / COLLATERAL MAP for a WARN-Act plant-death entity (the failing employer). Joins that entity to FREE-STATE UCC-encumbered collateral + secured parties (Colorado SOS, live keyless) + the county-recorder real-property lookout, and returns the encumbered-collateral inventory + liquidator/auctioneer/assignee actions. Buyers: distressed-asset liquidators, auctioneers, and the assignee running the wind-down — they NEED the collateral map to know what can sell free vs. what's locked by a perfected lien. Pass an entity (employer name) for the full map, or omit it for the recent plant-death TRIAGE feed (each with a CO-UCC collateral count). HONEST: WARN index is CA, UCC join is CO — a CA plant-death maps to CO collateral only for multi-state operators (honest null otherwise). Hand-verifiable at this volume; verify before bidding. [x402: full map settles $0.50 USDC on Base mainnet, keyless; free preview included.]
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Triage-feed size when no entity (default 12). | |
| entity | No | Failing employer / plant-death entity name (omit for the triage feed). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description carries full burden. It honestly discloses geographic limitations (CA WARN index, CO UCC join), potential null results for non-multi-state operators, and the need for verification. It also mentions pricing and a free preview. This adds significant behavioral context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action and progressively adds details. It is somewhat lengthy but every sentence contributes value, covering functionality, target users, usage options, limitations, and pricing. It could be slightly condensed without losing 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, the description outlines what is returned: encumbered-collateral inventory and liquidator/auctioneer/assignee actions. It covers the main aspects for its complexity, but lacks explicit differentiation from sibling tools like abc_asset_map. Edge cases and error handling are not mentioned.
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 descriptions for both parameters. The description adds meaning by explaining that 'entity' is the failing employer name and that omitting it switches to a triage feed. It provides usage context that goes beyond the bare schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it builds a liquidator-facing asset/collateral map for a WARN-Act plant-death entity. It specifies the verb 'build', the resource 'asset/collateral map', and distinguishes from siblings by being liquidator-focused and WARN-specific. The target audience is explicitly identified.
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 clear usage guidance: pass an 'entity' for the full map, or omit for the triage feed. It explains the context of liquidators, auctioneers, and assignees. However, it does not explicitly exclude alternatives or name sibling tools for 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.
warn_plant_deathsAInspectFREE: recent WARN-Act PLANT-DEATH events (mass layoffs / plant closures) — the SECOND distress-event lane feeding the same liquidation map. Each is a failing employer the day its plant is dying, with whether it has a live Colorado UCC collateral map (so a liquidator can triage which dying plant has filed collateral worth chasing). Live keyless index = CA EDD detailed WARN report; the CO UCC join is the collateral overlay (honest null where the firm's collateral is in a state not yet covered keyless). Feed an employer into warn_liquidation_map for the full collateral inventory.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max plant-death events (default 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns plant-death events with a collateral map indicator, and mentions data sources (CA EDD, CO UCC). It implies a read-only operation but does not explicitly state idempotency or side effects, which is acceptable for a query 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?
The description is a dense paragraph containing multiple technical details. While informative, it is not particularly concise or well-structured, with jargon that may reduce clarity. It could be more streamlined.
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 fails to explicitly outline the return structure or fields, despite the absence of an output schema. It mentions 'failing employer' and 'collateral map indicator' but does not specify the full set of fields, leaving the agent with incomplete context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single 'limit' parameter, with the description merely restating the schema's description. No additional semantic value is added beyond what the schema already provides, meeting the 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 identifies the tool's purpose: listing recent WARN-Act plant-death events (mass layoffs/plant closures) as the second distress-event lane for a liquidation map. It distinguishes itself from siblings by referencing the specific lane and pointing to warn_liquidation_map for full collateral inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use this tool (initial triage of dying plants) and directs users to warn_liquidation_map for deeper analysis. However, it lacks explicit guidance on when not to use it or alternatives beyond the mentioned sibling.
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!
