Skip to main content
Glama

Check LLC name availability

check_llc_name
Read-onlyIdempotent

Is this LLC name available, and can it be registered in these states? Returns a dated preliminary or live verdict for each state, the source registry portal, and the full results URL. This is not a name reservation; the state confirms at filing. Use check_business_name instead when the question is about anything else that could stop use of the name.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "name": "<name>",
      "states": "<states>"
    },
    "name": "check_llc_name"
  }
}

Input Schema

NameRequiredDescriptionDefault
nameYesThe business, LLC, or trademark name from the conversation. An LLC designator is optional.
statesYesUp to 5 two-letter state or DC codes from the conversation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, non-open-world, so the safety profile is covered. The description adds value beyond them: what is returned (dated preliminary or live verdict per state, source registry portal, full results URL) and the important caveat that a pass is not a reservation. It does not discuss latency, cost, or what distinguishes a preliminary from a live verdict, which keeps it below a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences ordered as purpose → return shape → caveat/alternative, with the core question front-loaded. Every sentence earns its place; only the rhetorical question phrasing costs a little directness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so (per-state verdict, date, registry source, results URL), plus the reservation caveat and the sibling routing. Remaining gaps are minor: no mention of the state-count limit or how preliminary vs. live verdicts differ in reliability.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters (name, states) are already documented in the schema, and the description adds only the notion that results are per-state. It does not mention the 5-state cap or the 2-letter code format, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource question (LLC name availability and registrability) scoped to states, and explicitly names the sibling check_business_name as the tool for other blockers. An agent can distinguish it from check_business_name, get_state_naming_rules, and check_trademark_conflicts without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use (LLC name availability/registrability by state), an explicit when-not (this is not a reservation; the state confirms at filing), and an explicit alternative with the condition that selects it (check_business_name for anything else that could stop use of the name).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources