US LLC filing fees, annual-report deadlines and naming-rule checks, from official state sources.
Scored across 8 tools
Each tool has a distinct purpose and the descriptions explicitly differentiate the potentially overlapping pairings (compare_llc_costs vs get_llc_fees, compare_formation_options vs compare_llc_costs, preview_order vs submit_order). The only mild risk is an agent confusing the broad state-ranking cost tool with the single-state fee lookup, but the descriptions clarify this well.
All eight tools follow a clean snake_case verb_noun pattern (check_llc_name, compare_llc_costs, get_llc_fees, list_filing_states, submit_order, etc.). No mixed conventions or stray casing; the pattern is fully predictable.
Eight tools is well-scoped for a business-formation service, with each tool earning its place across name screening, comparisons, fee/deadline lookups, coverage, and the order flow. Nothing feels redundant or padding.
The core formation lifecycle is well covered: name check, state/entity comparison, cost/fee/deadline data, coverage, and a gated preview-to-submit order flow. Minor gaps exist around post-submission order status tracking or cancellation, which agents would have to work around.
Screens a proposed business name against state naming rules. It does NOT search any state registry and cannot tell whether a name is already taken. Wyoming and Delaware: the entity designator where the statute requires one (such as "LLC"), words that are restricted or need agency approval (such as "Bank"; in Wyoming also "Trust" or "University"), and other state-specific rules. Florida: the required designator only. Other states and DC return verdict "unsupported" with a note pointing to the state's official name search. Verdicts: "conflict" means the name as written breaks a rule that blocks filing, including a missing required designator (reasons include a "Try:" suggestion where one applies); "uncertain" means no blocking rule was found (reasons may still list warnings) and availability is unverified. Wyoming, Delaware, and Florida results include verifyUrl, the state's official name search. Use when the user proposes a name for a new LLC or corporation in Wyoming, Delaware, or Florida.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The proposed name, e.g. "Blue Harbor Holdings LLC". | |
| state | Yes | State code or name. Full naming-rule screen: "WY", "DE". Designator check + Sunbiz link: "FL". Other states return "unsupported". | |
| entityType | No | Defaults to llc. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a safe, read-only, closed-world profile, and the description goes well beyond that: it enumerates the verdict vocabulary and what each verdict means, clarifies that "uncertain" does not mean available, notes reasons can carry a "Try:" suggestion, and states which states include a verifyUrl. This is exactly the kind of scope and result-semantics disclosure an agent 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?
Purpose and the critical limitation are front-loaded, and the per-state and per-verdict detail is information-dense rather than padded. It is nonetheless a long, single-block passage that could be segmented (limitations / per-state behavior / verdicts) for faster scanning.
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 carries the return-value burden and does so: verdict values, the meaning of conflict vs uncertain, reason contents, and verifyUrl availability by state. Combined with the documented inputs, an agent has everything needed to call it and interpret the result.
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 baseline is 3, but the description adds real meaning for the state parameter by mapping "WY"/"DE" to a full screen, "FL" to designator-only, and everything else to "unsupported" with an official-search pointer. The entityType parameter is left to the schema, which documents its default, so this falls short of a 5.
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?
It states a precise verb and resource (screens a proposed business name against state naming rules) and immediately draws the boundary that matters most: it does NOT search any state registry and cannot tell whether a name is taken. Sibling tools are cost, deadline, and filing operations, so a screening/validation tool is unambiguously distinct.
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 closing sentence gives an explicit trigger ("Use when the user proposes a name for a new LLC or corporation in Wyoming, Delaware, or Florida") and the description spells out the when-not case: other states return "unsupported" and route the user to the state's official name search. Nothing about scope selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns fixed, factual tradeoffs for deciding WHERE to form (topic "state": the home state versus Wyoming, Delaware, and Nevada, including the cost of foreign-qualifying back into the home state) or WHAT entity type to use (topic "entity_type": LLC versus the S-corp tax election versus C-corp), plus a required disclaimer. Deliberately not a recommendation: the options are meant to be presented neutrally with the disclaimer, leaving the choice to the user. Use when the user asks which state to form in, whether to form out of state, or which entity type suits their business.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | "state" for where to form, "entity_type" for LLC vs S-corp vs C-corp. | |
| homeState | No | Optional. The state the user actually lives or operates in — lets the comparison include their home-state costs, which usually matter most. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/openWorldHint=false, so safety is covered, but the description adds meaningful beyond-schema behavior: the result is deliberately non-prescriptive and includes a required disclaimer that must be presented neutrally to the user. It doesn't discuss error cases or limits, but for a static comparison tool the added output-handling guidance is substantive.
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?
Front-loads what is returned and the two topic modes; every sentence carries information (scope, disclaimer, neutrality, triggers). Dense but not padded; the parenthetical enumerations are long yet purposeful.
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 carries the return-value burden and does so — result content, the required disclaimer, and the neutral-presentation requirement are all stated, along with when to call it and what each parameter controls.
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 already 100%, so baseline is 3, but the description adds intent-level meaning: it explains that 'homeState' lets the comparison include the user's home-state costs 'which usually matter most' — beyond the schema's plainer wording.
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?
States a precise verb+resource ('returns fixed, factual tradeoffs') and enumerates exactly what each topic value returns (home state vs Wyoming/Delaware/Nevada, foreign-qualification cost; LLC vs S-corp election vs C-corp). An agent can distinguish this from compare_llc_costs without opening either schema.
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 names the triggering user intents: 'which state to form in, whether to form out of state, or which entity type suits their business.' It gives clear use conditions but names no exclusions or sibling alternatives (e.g., when to use compare_llc_costs instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ranks US states by LLC cost: the one-time formation fee, the recurring state fee, or the first-year total (formation plus one recurring period). Use when the user asks which state is cheapest to form or maintain an LLC in, or wants LLC costs compared across specific states. Covers all 50 states + DC. State fees only — registered-agent fees, service fees, and revenue-based taxes are excluded. Returns figures only, without source URLs; get_llc_fees returns a state's official sources.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many states to return. Defaults to 10. | |
| sortBy | No | Which cost to sort ascending by. Defaults to firstYear (formation + one recurring period). | |
| states | No | State codes or names to compare. Omit to rank all 50 states + DC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare a read-only, non-destructive, closed-world operation, so the safety bar is low. The description goes further by disclosing cost scope (state fees only, excludes registered-agent/service fees and revenue-based taxes) and return limitations (figures only, no source URLs) — valuable context beyond the 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?
Four tight sentences, all front-loaded: what it ranks, when to use it, what it covers/excludes, and what it returns. No filler or 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?
No output schema exists, but the description compensates by stating what is returned (figures only) and what is omitted (source URLs), plus geographic coverage (all 50 states + DC). An agent has everything needed to call and interpret results.
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 all three parameters are already documented, including the enum meaning and the default. The description's parenthetical on first-year total (formation plus one recurring period) largely repeats the schema, adding only marginal value. Baseline 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?
States a specific verb and resource ('Ranks US states by LLC cost') and enumerates the three ranking bases (formation, recurring, first-year total). It is immediately distinguishable from get_llc_fees, which it explicitly contrasts as the source-URL tool.
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?
Gives explicit trigger conditions ('Use when the user asks which state is cheapest to form or maintain an LLC in, or wants LLC costs compared across specific states') and names the alternative tool to use when official sources are needed. Nothing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculates when an LLC's next annual report or franchise tax is due in a given state and the amount owed, and returns the state's rule text, late-filing consequences where the dataset has them (penaltyAndNotes), and the official state source URLs. Use when the user asks when their LLC's annual report is due, how often it is filed, or what happens if it is late. States that key the deadline to the formation anniversary or quarter need formationDate; without it the tool says so instead of guessing a date.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code or full state name, e.g. "WY" or "Wyoming". All 50 states + DC. | |
| formationDate | No | The LLC's formation date as ISO yyyy-mm-dd. Required for anniversary- and quarter-based states. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only and non-destructive nature of the tool. The description adds valuable behavioral details: it returns rule text, penalty notes where available, and official source URLs; it also states that the tool will not guess a date if formationDate is missing, instead prompting the user. This goes beyond standard annotations and is useful.
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 composed of three efficient sentences, front-loaded with the purpose and followed by usage conditions and a key behavioral constraint. It is well-structured and contains no unnecessary filler, though it could be slightly more concise by combining some phrases.
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 (computation + data retrieval), annotations (read-only), and the absence of an output schema, the description is largely complete for an agent to invoke it correctly. It explains the outputs and the conditional parameter requirement, but lacks details on the format of the returned rule text or amount (e.g., currency) – minor gaps.
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 defines the parameters. The description adds meaningful context about formationDate: it is required for anniversary- and quarter-based states, and the tool will indicate its absence without guessing. This extra information helps the agent understand when and why to supply the parameter.
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 specifies the exact calculation performed (next annual report or franchise tax due), the input scope (given state), and the additional outputs (amount owed, rule text, late-filing consequences, source URLs). It clearly distinguishes this tool from siblings like get_llc_fees or check_llc_name, which serve different purposes.
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 explicit usage triggers: when the user asks when the annual report is due, how often it is filed, or what happens if it is late. It does not explicitly name alternative tools, but the context is clear enough that an agent can infer this is the right tool for deadline-related queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns one US state's LLC formation fee, its recurring annual-report or franchise-tax cost and cadence, online processing time, and known gotchas such as publication requirements, plus a labeled list of the official state source URLs the figures were taken from (dataset verified 2026). Use when the user asks what it costs to form or keep an LLC in a specific state. Covers all 50 states + DC.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code or full state name, e.g. "WY" or "Wyoming". All 50 states + DC. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld=false/non-destructive, so the safety profile is covered. The description adds real value beyond them: it enumerates what is returned (fees, cadence, processing time, gotchas, labeled official source URLs) and discloses data provenance/freshness ("dataset verified 2026").
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?
Front-loaded with the payoff (what the tool returns) and each sentence earns its place, including the usage trigger. The trailing "Covers all 50 states + DC" mildly duplicates the state parameter's own description.
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 must carry the return-value burden, and it does: it names every field category returned plus the source-URL list and dataset vintage. For a single-parameter read-only lookup this is complete enough to invoke confidently.
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% and the single `state` parameter is documented with both accepted formats ("WY" or "Wyoming"). The description adds no syntax or format detail beyond the schema, so the baseline 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?
States a specific verb (get/returns) and resource (one state's LLC formation fee, annual-report cost and cadence, processing time, gotchas, source URLs). The explicit "one US state's" scoping cleanly separates it from the multi-state sibling compare_llc_costs without the agent needing to open either schema.
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?
Gives a clear triggering condition: "Use when the user asks what it costs to form or keep an LLC in a specific state." It does not name alternatives (e.g. compare_llc_costs for multi-state or preview_order for purchasing) or state when not to use it, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists FilingDesk's coverage: the states it files formations in today with all-in prices, the states its naming-rule screen supports, and fee/deadline data coverage (all 50 states + DC). Use when the user asks which states FilingDesk can file in, or before stating that FilingDesk can file in a particular state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds real behavioral context beyond that: coverage is split into three distinct capability tiers (filing, name screening, fee/deadline data), and the 'today' phrasing signals this is a live snapshot that may change, which matters before making coverage claims.
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?
One sentence defines the content, one sentence defines when to call it. Front-loaded with the resource and scope, no filler, nothing redundant.
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 carries the burden of describing returns, and it does so at the level of content categories (filing states, naming-rule states, fee/deadline coverage including all 50 states + DC). It does not describe the shape of the response, but for a simple enumeration tool the content-level description is sufficient.
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?
Zero parameters, so the schema places no interpretive burden on the description. The description correctly implies a no-argument lookup that returns coverage dimensions, matching the empty input 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?
States a specific verb and resource ('Lists FilingDesk's coverage') and breaks that coverage into three concrete dimensions: filing states with all-in prices, naming-rule screen support, and fee/deadline data. This is clearly distinguishable from siblings like get_llc_fees, check_llc_name, and get_annual_report_deadline.
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?
Gives explicit triggers: when the user asks which states FilingDesk can file in, and as a precondition before asserting FilingDesk can file in a given state. It does not name a competing sibling tool or state exclusions, but the trigger conditions are concrete enough to route the agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validates and prices a formation order and returns the exact summary that would be submitted, WITHOUT submitting anything (no side effects). Use when the user wants FilingDesk to form their LLC or corporation and has provided the business name, state, entity type, and their name, email, and phone. The returned summary is meant to be shown to the user verbatim, and this step is required before submit_order.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The customer's email. Required — this is where documents go. Temporary/disposable inboxes are rejected. | ||
| phone | Yes | The customer's phone number with area code. Required — used only if the state or the specialist has a question about the filing. | |
| state | Yes | Two-letter state code or full state name, e.g. "WY" or "Wyoming". All 50 states + DC. | |
| fullName | Yes | The customer's full name. | |
| entityType | Yes | Entity type, e.g. "LLC", "S-Corp", "C-Corp", or "Not sure" if the user hasn't decided. | |
| description | No | One or two sentences on what the business does. Optional — the user may skip it. | |
| businessName | Yes | Proposed company name. Does not need to be final — a specialist verifies availability. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description is consistent with them while adding genuine context: no side effects, the returned summary is meant to be shown to the user verbatim, and it is a mandatory precursor to submit_order. It does not cover failure modes or validation-rejection behavior, which keeps it short of 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both front-loaded: the core action and its no-side-effect guarantee come first, followed by the usage condition and the sequencing requirement. No filler or restated title.
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?
Although no output schema exists, the description explains what comes back ('the exact summary that would be submitted') and how to handle it (show verbatim), plus the required precondition. For a 7-param read-only tool, this leaves nothing important unstated.
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 each parameter already carries its own guidance (all 50 states + DC, disposable-inbox rejection, etc.). The description only recaps which fields the user must provide, adding no syntax or format detail beyond the schema, so baseline 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?
The description gives a specific verb pair and resource ('validates and prices a formation order') and states the key scope constraint ('WITHOUT submitting anything'). It is immediately distinguishable from the sibling submit_order, which it names 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?
It states exactly when to use it (user wants to form an LLC/corp and has supplied name, state, entity type, and contact info) and where it sits relative to the alternative: 'this step is required before submit_order.' The no-side-effects framing also signals when to prefer this over the real submission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submits a formation order to FilingDesk. THIS HAS A REAL-WORLD EFFECT: it records the order, notifies a FilingDesk specialist, and may send an automatic order-confirmation email to the customer's email address. The specialist then reviews the order, confirms name availability and the price, and emails a payment link. Nothing is charged at submission. Call only after preview_order, once the user has explicitly confirmed that summary (userConfirmed: true). Returns the order reference (FD-…).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | The customer's email. | ||
| phone | Yes | The customer's phone number (required). | |
| state | Yes | Two-letter state code or full state name, e.g. "WY" or "Wyoming". All 50 states + DC. | |
| fullName | Yes | The customer's full name. | |
| entityType | Yes | Entity type, e.g. "LLC", or "Not sure". | |
| description | No | What the business does. Optional. | |
| businessName | Yes | Proposed company name. | |
| userConfirmed | Yes | Must be true. Set only after the user has seen the preview_order summary and explicitly agreed to submit. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations by disclosing the concrete real-world effects: recording the order, notifying a specialist, possibly emailing the customer, and that nothing is charged at submission. This is exactly the kind of side-effect context the destructiveHint/openWorldHint flags cannot convey. It stops short of describing failure modes or how to retry after a failed submission, so it is not quite 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the action and the critical real-world warning, and every sentence carries information (side effects, no-charge note, gating condition, return value). Slightly dense, but no sentence is filler.
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 mutating tool with full annotation coverage and a complete schema, the description supplies the missing pieces: the workflow prerequisite, the confirmation requirement, the real-world consequence, and the return format (order reference FD-…). Nothing needed to invoke it safely is absent.
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 all eight fields, including the exact semantics of userConfirmed. The description only reinforces the userConfirmed gate and notes the returned order reference, adding little parameter meaning beyond the schema; 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?
States a specific verb and resource ('Submits a formation order to FilingDesk') and immediately distinguishes itself from the sibling preview_order by describing the actual submission side-effect. An agent can tell this apart from preview_order and the informational siblings 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gates usage: 'Call only after preview_order, once the user has explicitly confirmed that summary (userConfirmed: true).' It names the prerequisite tool and the exact condition that selects this tool, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_llc_name1 field changedInput schema / properties / state / descriptionPrevious value: -"State code or name. Live checks: \"WY\", \"DE\". Link-only: \"FL\"."New value: +"State code or name. Full naming-rule screen: \"WY\", \"DE\". Designator check + Sunbiz link: \"FL\". Other states return \"unsupported\"."preview_order3 fields changedInput schema / properties / email / descriptionPrevious value: -"The customer's email. Required — this is how they are contacted."New value: +"The customer's email. Required — this is where documents go. Temporary/disposable inboxes are rejected."Input schema / properties / phone / descriptionPrevious value: -"Optional phone number."New value: +"The customer's phone number with area code. Required — used only if the state or the specialist has a question about the filing."Input schema / requiredPrevious value: -[
- "businessName",
- "state",
- "entityType",
- "fullName",
- "email"
-]New value: +[
+ "businessName",
+ "state",
+ "entityType",
+ "fullName",
+ "email",
+ "phone"
+]submit_order2 fields changedInput schema / properties / phone / descriptionPrevious value: -"Optional phone number."New value: +"The customer's phone number (required)."Input schema / requiredPrevious value: -[
- "businessName",
- "state",
- "entityType",
- "fullName",
- "email",
- "userConfirmed"
-]New value: +[
+ "businessName",
+ "state",
+ "entityType",
+ "fullName",
+ "email",
+ "phone",
+ "userConfirmed"
+]check_llc_namecompare_formation_optionscompare_llc_costsget_annual_report_deadlineget_llc_feeslist_filing_statespreview_ordersubmit_orderUS company filing obligations, plus a 25-check bookkeeping diagnostic. Sourced, dated, no signup.
State-by-state LLC dissolution: exact fees, forms, official state links. Not legal advice.
Verify a US business exists and is active by name + state. Status, formation date, agent.
Verify a US company is registered and active from official state registry open data.
Add one secure layer between your agents and this server.
