OpenSOSData
Server Details
Real-time US business entity search across all 53 US jurisdictions - all 50 states, DC, Puerto Rico, and US Virgin Islands. Search, verify, and check the status of any LLC, corporation, or registered entity. Ideal for KYB, due diligence, and vendor verification.
- Status
- Unhealthy
- 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.2/5 across 7 of 7 tools scored.
Most tools have distinct purposes (e.g., name availability checking vs. status verification), but batch_search and search_business_entity serve similar roles (batch vs. single) which could cause minor confusion.
Tool names follow a verb_noun pattern in snake_case (e.g., check_entity_status, search_business_entity). Minor inconsistency: batch_search starts with a noun qualifier rather than a verb.
Seven tools cover the core domain (search, status, availability, jurisdictions, UCC) without being excessive or insufficient.
The toolset covers key read operations for US business entities and UCC filings. Lacks advanced features like historical data or filing uploads, but is complete for typical due diligence workflows.
Available Tools
7 toolsbatch_searchARead-onlyInspect
Search for multiple business entities simultaneously across different states. Maximum 10 entities per batch. Returns results for each entity in order.
| Name | Required | Description | Default |
|---|---|---|---|
| searches | Yes | List of entities to search (max 10) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds useful behavioral info: returns results in order. No further traits like rate limits or error behavior are disclosed, but annotations reduce the burden.
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: two sentences with no wasted words. It front-loads the core purpose, then adds constraints and behavior.
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 one parameter (array) and no nested objects, the description is fairly complete. It mentions return ordering but lacks details on error handling or output format. Given no output schema, 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 description coverage is 100%, so the schema already documents parameters with descriptions. The description restates the max 10 constraint but adds no new semantic meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching multiple business entities simultaneously across states. It differentiates from siblings like search_business_entity (likely single entity) and list_supported_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?
The description explicitly limits batch size to 10 entities, providing clear usage guidance. It doesn't directly mention when not to use it or list alternatives, but the context of sibling tools implies differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_entity_statusARead-onlyInspect
Verify if a business entity is active, inactive, or dissolved in a specific US jurisdiction. Ideal for KYB compliance, due diligence, and vendor verification workflows.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter US state or territory code | |
| entity_name | Yes | The business entity name to check |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds specific behavioral detail: the tool returns status categories (active, inactive, dissolved). This is good context that goes beyond annotations, though additional details (e.g., rate limits, error handling) are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, followed by use cases. 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?
For a simple tool with 2 parameters and no output schema, the description adequately covers purpose and usage context. It does not describe the return format explicitly, but the mention of 'active, inactive, or dissolved' gives sufficient indication. Missing details like error handling or pagination are not critical here.
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 clear descriptions for both parameters ('Two-letter US state code', 'business entity name'). The description does not add new semantic details beyond what the schema provides, so baseline 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 verb 'Verify' and the resource 'business entity status' (active, inactive, dissolved) in a specific US jurisdiction. It also lists use cases (KYB, due diligence, vendor verification) and distinguishes from siblings like check_name_availability or search_business_entity by focusing on status.
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 by mentioning ideal workflows (KYB, due diligence, vendor verification), implying when to use. However, it does not explicitly state when not to use it or name alternatives, which would be helpful for an AI agent deciding among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_name_availabilityARead-onlyInspect
Check whether a business name is available to register in a US state or territory. Returns available: true/false plus up to 10 conflicting entity matches sorted by status (active first). Useful for business formation workflows, pre-registration research, and name conflict detection. Always queries live portal data.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter US state or territory code (e.g. CA, DE, NY) | |
| entity_name | Yes | Business name to check availability for |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds value by stating 'Always queries live portal data' and detailing return structure (up to 10 conflicting entities sorted by status).
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 clear front-loading: first sentence states core purpose, second details output, third provides usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description adequately explains return values (available boolean, conflicting matches). Parameters are fully documented in schema, and usage context is provided. Complete for a simple read 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?
Input schema covers both parameters with descriptions (100% coverage). Description does not add additional parameter-level details beyond the schema, so baseline of 3 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?
Description clearly states the verb 'Check' and resource 'business name availability' in a specific scope (US state or territory). It also distinguishes from siblings by specifying the output format (available: true/false plus conflicting matches).
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 lists explicit usage contexts (business formation, pre-registration research, name conflict detection) and states live portal data, but does not mention when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jurisdictions_for_regionARead-onlyInspect
Get the list of US jurisdictions in a specific region. Useful for multi-state compliance checks and understanding regional coverage.
| Name | Required | Description | Default |
|---|---|---|---|
| region | Yes | US region to get jurisdictions for |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive nature. Description adds no further behavioral traits beyond what annotations provide.
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 redundant information. Every word 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 read-only tool with one parameter, description adequately conveys purpose and context. Could optionally mention output format but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with enum values and parameter description. Tool description adds 'US' context but not meaningful extra semantics beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Verb 'Get' and resource 'list of US jurisdictions in a specific region' is clear and specific. Distinguishes from sibling list_supported_jurisdictions by specifying 'US' regional filtering.
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 usefulness for compliance checks and regional coverage but lacks explicit when-not-to-use or comparison with sibling tools like list_supported_jurisdictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_supported_jurisdictionsARead-onlyInspect
Returns all 53 US jurisdictions with live business entity search coverage, including all 50 states, Washington DC, Puerto Rico, and US Virgin Islands.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds specific behavioral context: the tool returns all 53 jurisdictions with live coverage, including specific territories. This goes beyond the annotations' generic safety hints, providing concrete output scope.
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 detail. Every word adds value, no redundancy, and it is front-loaded with the core action.
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 (no parameters, no output schema), the description fully covers what the tool returns. It specifies the count (53), the coverage (US jurisdictions with live search), and lists the included entities. No additional context is needed for an agent to correctly select and invoke this 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 tool has zero parameters and the input schema is empty. With 0 parameters, the baseline is 4. The description does not need to add parameter semantics, and it appropriately focuses on the output.
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 all 53 US jurisdictions with live business entity search coverage, listing specific entities. It uses specific verb 'Returns' and resource 'US jurisdictions', and the explicit enumeration (50 states, DC, PR, USVI) distinguishes it from sibling tools like search_business_entity or check_entity_status.
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 when to use this tool (to get a list of supported jurisdictions) and implicitly differentiates from siblings that search or check specific entities. However, it does not explicitly state when not to use it or mention alternatives, which would push it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_business_entityARead-onlyInspect
Search for a US business entity by name in a specific state or territory. Returns entity name, ID, status, type, registered agent, and address. Covers all 53 US jurisdictions including DC, Puerto Rico, and US Virgin Islands.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter US state or territory code (e.g. CA, NY, TX, DC, PR, VI) | |
| entity_name | Yes | The business entity name to search for |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds context on return fields and jurisdiction coverage, which is helpful beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and scope. No 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 no output schema, the description lists key return fields. Missing pagination or matching behavior, but overall adequate for a search 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% with clear descriptions for both parameters. The description does not add extra meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for US business entities by name in a specific state, and lists the returned fields. It distinguishes from siblings like check_entity_status and search_ucc_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 implies usage for name+state searches but does not explicitly contrast with sibling tools like batch_search or check_name_availability. No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_ucc_filingsARead-onlyInspect
Search UCC (Uniform Commercial Code) lien filings by debtor name in a specific US state. Returns filing number, status (active/lapsed/terminated), debtor and secured party details, filing and lapse dates, and collateral description. Useful for due diligence, lien searches, and credit risk assessment.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter US state code. Supported: AK, AL, AZ, CA, CO, CT, FL, IA, ID, IN, KY, MA, MO, MS, MT, NC, ND, NJ, NM, NY, OH, OR, PA, RI, TN, VA | |
| debtor_name | Yes | The debtor name to search for (person or business) | |
| max_results | No | Maximum number of filings to return (1-30, default 10) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description's addition of return details (filing number, status, parties, dates, collateral) provides valuable behavioral context beyond the structured annotations, even though it does not disclose rate limits or other potential behaviors.
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 succinct, with two sentences that efficiently convey the action, inputs, and outputs. It is front-loaded with the verb and resource, and 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?
Given the moderate complexity, full schema coverage, and annotations that cover safety, the description is complete enough. It explains what the tool returns and its typical use cases, leaving no critical gaps for an agent to select and invoke 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 description coverage is 100%, with clear descriptions for all three parameters. The description does not add significant new meaning beyond what the schema already provides, so it meets the baseline 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 states it searches UCC lien filings by debtor name in a US state. It distinguishes itself from sibling tools like search_business_entity which operate on business entities, not UCC 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 includes use cases such as due diligence and lien searches, providing clear context for when to use this tool. However, it does not explicitly mention when not to use it or compare with alternatives, though the distinction is implicit.
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!