Look up any New York LLC: publication deadline, county and price. Quotes for NY LLC filings.
Scored across 8 tools
Most tools map to clearly distinct jobs: name check vs. existing LLC lookup, publication law explanation vs. publication price, formation quote vs. other-filing prices, and final order start. The main overlap is among cost-related tools—get_publication_price, lookup_new_york_llc, quote_llc_formation, and get_filing_service—but descriptions mostly route by new/existing/specific/other-service context. get_publication_price's phrase 'Use for any cost question' slightly overclaims and could cause some confusion.
All names are snake_case and follow an action-oriented verb_noun pattern (check_, explain_, get_, lookup_, quote_, start_). Long or acronym-containing names like get_ny_llc_formation_statistics are still predictable and no mixed conventions appear.
Eight tools is well within a reasonable range for a focused New York LLC filing and publication service. Each tool earns its place across name selection, pricing, compliance explanation, lookup, statistics, and ordering. There is no obvious bloat or thinness.
The set covers the core customer journey: check a name, understand publication, price publication/formation/other filings, look up an existing LLC, and start an order. Minor gaps remain around order status/tracking and a dedicated explanation of LLC formation requirements, though agents can largely work around them via quote_llc_formation and start_order. For the publication-focused scope, coverage is strong.
Checks whether a proposed name for a NEW New York LLC or PLLC is free on the state's live register, the way the Department of State compares names (ignoring case, punctuation, the LLC ending and a leading 'The'). Returns the name as it would be filed, whether it is taken, and similar existing names. Advisory: the Department of State has the final word. Use when someone is choosing a name or planning to form an LLC.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | llc (default) or pllc for licensed professions. | |
| name | Yes | The proposed name, with or without LLC at the end. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only carry the generic safety profile (readOnly, idempotent, openWorld, non-destructive); the description adds the substantive behavior that matters: the exact comparison rules the Department of State applies (case, punctuation, LLC ending, leading 'The'), what the response contains, and the advisory caveat that the state has final say.
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 tight sentences, front-loaded with what is checked and under what comparison rules, then return contents, then the caveat and usage trigger. No 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?
With no output schema, the description compensates by naming the return fields (filed-form name, taken flag, similar existing names). Combined with full schema coverage and annotations, an agent has everything needed to call it 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 coverage is 100% so the baseline is 3, but the description adds real interpretation value: it explains how the 'name' input is normalized and evaluated against the register, and 'NEW New York LLC or PLLC' clarifies the role of the kind parameter (llc vs pllc for licensed professions).
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 (checks availability of a proposed name) on a specific resource (New York LLC/PLLC name register), and scopes it to NEW entities, which cleanly separates it from the sibling lookup_new_york_llc (an existing-entity lookup). An agent can pick between them without opening a 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 trigger: 'Use when someone is choosing a name or planning to form an LLC.' It does not name a competing sibling or state when NOT to use it, but the context is unambiguous for the naming/formation stage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explains New York's LLC publication requirement (LLC Law §206 for New York LLCs, §802 for out-of-state LLCs registered in New York): who must publish, how (two newspapers designated by the county clerk, one daily and one weekly, once a week for six weeks), the 120-day deadline and when it starts, what happens if it is missed (authority suspended, no fine, curable by publishing late), and whether it repeats (it does not). Use for 'do I have to publish', 'what happens if I don't', 'I missed the deadline' and similar. Do NOT use for prices (get_publication_price) or a specific LLC (lookup_new_york_llc).
| Name | Required | Description | Default |
|---|---|---|---|
| situation | No | What the user is asking about. Default general. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so safety is covered. The description still adds substantive behavioral content beyond that: the 120-day deadline, that missing it suspends authority without a fine, that it is curable by publishing late, and that the requirement does not repeat.
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 substantive answer content is front-loaded before the usage and exclusion clauses, and every clause carries information. It is long, but the length is justified by the breadth of legal topics the tool must cover in one call.
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?
Covers the full scope an agent needs: statutory basis for both LLC types, mechanics, deadline, consequences, curability, and recurrence, plus routing to alternatives. With no output schema present, this description is sufficient to predict the response content.
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 'situation' enum is fully documented with a stated default, so the schema carries the parameter burden. The description's example phrases loosely imply situations but add no syntax or mapping detail beyond the enum, so the 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?
The description names a specific verb (explains) and resource (NY LLC publication requirement), then enumerates the exact sub-topics covered (who publishes, how, deadline, penalties, recurrence). It distinguishes itself from siblings by naming get_publication_price and lookup_new_york_llc as different tools.
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?
Explicit when-to-use phrasings are quoted ('do I have to publish', 'I missed the deadline') and an explicit do-not-use clause routes price questions and entity-specific questions to named alternatives. Both sides of the routing decision are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prices and explains Cheap NY Publication's other New York LLC filings, all in with the state fee: the Biennial Statement (New York's every-two-years report; there is no annual report), a Certificate of Good Standing (Certificate of Status), a DBA (Certificate of Assumed Name) for an LLC, and a county change (Certificate of Change). The Biennial Statement and the Certificate of Good Standing are for business corporations too. For a Biennial Statement, pass the company's filing date to get the month it is due. Use for any of these four.
| Name | Required | Description | Default |
|---|---|---|---|
| service | Yes | ||
| filing_date | No | Biennial only: the LLC's or corporation's original filing date (YYYY-MM-DD), to find the due month. | |
| assumed_name | No | DBA only: the name to trade under, to check it is allowed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real context: pricing is 'all in with the state fee,' each service is glossed, and the filing-date-to-due-month behavior is disclosed. No auth or rate-limit notes, but that is minor here.
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 purpose, then the service list, then the two edge notes. Parenthetical glosses are dense but each carries distinct information; nothing 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 three-parameter tool with one required enum and no output schema, the description covers purpose, the enum's four members, and the conditional parameter behavior. The response shape (price plus explanation) is implied by 'prices and explains' rather than stated, which is the only small gap.
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 67%, and the description's parameter hints ('Biennial only' for filing_date, DBA-only assumed_name) largely restate the schema's own descriptions. It adds only a marginal output-facing detail, that the filing date yields the due month, which the schema does not say. Baseline 3 is right.
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 pair (prices and explains) and enumerates the exact resource set: Biennial Statement, Certificate of Good Standing, DBA, and county change. The word 'other' scopes it away from the publication-pricing siblings without needing to name them.
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?
Ends with an explicit routing instruction ('Use for any of these four') and gives a conditional for the Biennial Statement case. It never names a competing sibling (e.g. get_publication_price) to explicitly exclude, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns how many LLCs were formed in New York in the latest full month, the change from a year earlier, the year to date, the top counties, New York City's share and the share filed through commercial registered agents, from the Department of State's register (refreshed daily) as analyzed by Cheap NY Publication. Use for questions about how many LLCs are formed in New York, trends, or counties.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: the data source (Department of State's register) and freshness (refreshed daily), plus the analysis provider and the fact that the response is a bundle of aggregate metrics rather than records.
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 the return content and closed with the routing sentence. The long metric enumeration is dense but each item earns its place since there is no output schema to carry that information; only the attribution clause ("as analyzed by Cheap NY Publication") is arguably incidental.
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 parameters and no output schema, the description carries the full load and does so: it enumerates returned fields, gives data provenance, states refresh cadence, and states when to use it. An agent can call it and interpret the response without further information.
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 takes zero parameters, which is the baseline-4 case. The description correctly signals that no input is needed by framing the output as a fixed monthly statistics bundle, with no suggestion of filters that would require arguments.
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 (returns) and a specific derived resource (New York LLC formation statistics), then enumerates the exact metrics returned: latest-month count, year-over-year change, year-to-date, top counties, NYC share, and commercial registered agent share. This clearly separates it from sibling entity-lookup tools like lookup_new_york_llc or check_llc_name_availability.
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?
"Use for questions about how many LLCs are formed in New York, trends, or counties" gives clear affirmative usage context. It does not, however, name what this tool is NOT for or point the agent to lookup_new_york_llc for single-entity questions, so the routing is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns Cheap NY Publication's all-in price to complete New York LLC publication for an LLC in a given county, for a New York LLC or an out-of-state (foreign) LLC, with what the price includes. Two ways are priced: the LLC's county changed to a lower-cost county, where the designated newspapers cost far less (the change is filed for the customer and included), or publishing directly in the LLC's own county. Optionally compares a second county. Accepts borough names (Manhattan, Brooklyn, Staten Island). Use for any cost question. If the user names a specific LLC, use lookup_new_york_llc instead.
| Name | Required | Description | Default |
|---|---|---|---|
| county | Yes | The New York county or NYC borough where the LLC's office is on file, e.g. Kings, Manhattan, Westchester. | |
| llc_type | No | domestic = formed in New York; foreign = formed in another state and registered in New York. Default domestic. | |
| compare_to | No | Optional second county to compare. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description adds real substance beyond that — that the county-change route includes the filing being handled for the customer, what the price covers, and that borough aliases are accepted. It stops short of stating freshness of pricing or any rate/quote caveats, which keeps it from 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-loaded with the core outcome, then pricing routes, then the routing rule. The middle sentences are dense and slightly run-on, but every sentence carries either scope, behavior, or routing 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?
No output schema exists, and the description does address what comes back ('with what the price includes'). For a 3-parameter read-only pricing lookup that is close to sufficient; only price freshness/validity is left unaddressed.
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 meaning the schema does not: that the two priced routes hinge on the county argument, that compare_to is a second county used for comparison, and that borough names (Brooklyn, Staten Island) are accepted even though they are not counties.
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 ('returns ... all-in price to complete New York LLC publication') with the scope narrowed to a county and LLC type. It explicitly separates itself from lookup_new_york_llc, so an agent can route 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?
Gives an explicit positive trigger ('Use for any cost question') and an explicit exclusion with the alternative named ('If the user names a specific LLC, use lookup_new_york_llc instead'). The two pricing routes are also described as conditions, not just outputs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Searches New York State's live business register (Department of State data on data.ny.gov, updated daily) by LLC name or DOS ID. For each match returns the entity type, the county on file, the filing date, the 120-day publication deadline with days left or how long ago it passed, the month the next Biennial Statement is due, and the exact all-in price to publish it. Use whenever the user names a specific LLC or asks about their own deadline, county or price. Do NOT use for a name that is not formed yet (use check_llc_name_availability).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | The LLC's name (or the start of it) or its DOS ID number. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety behavior is covered; the description goes further by disclosing that the data is live Department of State data refreshed daily and by enumerating the returned fields (entity type, county, filing date, 120-day deadline with days remaining/elapsed, biennial statement month, all-in price). With no output schema present, that disclosure of result content is exactly the extra context needed.
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, front-loaded with the source and match key, then usage conditions, then the exclusion. Every sentence carries distinct information; nothing is redundant padding.
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 single-parameter read-only lookup with no output schema, the description supplies the data provenance, freshness, the full set of returned fields, and the routing rule to the sibling tool. Nothing an agent needs to select or invoke it correctly 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?
Schema description coverage is 100% with a single documented parameter, so the schema already explains that 'query' accepts a name, a name prefix, or a DOS ID. The description restates the same name-or-DOS-ID distinction ('or the start of it') without adding format, normalization, or matching-behavior detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.
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 ('Searches New York State's live business register ... by LLC name or DOS ID') and names the authoritative source and update cadence, so the agent knows exactly what is being looked up. It also implicitly separates itself from formation-side siblings by scoping to already-formed entities.
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 an explicit trigger ('Use whenever the user names a specific LLC or asks about their own deadline, county or price') and an explicit exclusion with a named alternative ('Do NOT use for a name that is not formed yet (use check_llc_name_availability)'). Both the when and the when-not are covered with the routing target spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Prices forming a new New York LLC (or PLLC) together with its required publication, line by line: the $200 Articles of Organization state fee, publication in Albany County or the LLC's own county, and add-ons (an EIN, a DBA, PLLC licensing). Several LLCs in one order (up to 10, e.g. one per property) take $10 off each LLC after the first. Use when someone plans to form an LLC and asks what it costs.
| Name | Required | Description | Default |
|---|---|---|---|
| dba | No | Add a DBA (Certificate of Assumed Name). One LLC only. | |
| ein | No | Add an EIN obtained for the LLC. | |
| kind | No | llc (default) or pllc. | |
| count | No | How many LLCs in the order. Default 1. | |
| own_county | No | Publish in this county instead of Albany (usually costs more). Omit for Albany. | |
| profession | No | For a PLLC: the licensed profession. | |
| member_count | No | For a PLLC: number of members. Default 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, so safety is covered; the description adds real behavioral context beyond them — the $200 state fee, county-dependent publication cost, optional add-ons, and the $10-per-LLC discount after the first when ordering up to 10. It stops short of describing how the quoted total is returned.
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 dense pricing sentence followed by a short usage sentence; the highest-value facts (what is priced, add-ons, discount) are front-loaded. The first sentence is long but each clause carries pricing information an agent would otherwise miss.
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 read-only quoting tool with rich annotations and full parameter documentation, the description supplies the pricing model an agent needs to answer cost questions. With no output schema, it would be slightly stronger if it noted that the response is a per-line breakdown with a total.
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 each field; the description still adds cross-parameter meaning by tying own_county to higher publication cost and count to the multi-LLC discount, and framing dba/ein/profession as optional add-ons rather than standalone flags.
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: pricing LLC/PLLC formation plus mandatory publication in New York, broken out line by line. It is clearly distinguishable from siblings like get_publication_price (publication only) and start_order (placing the order).
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?
"Use when someone plans to form an LLC and asks what it costs" gives an explicit trigger condition. It does not, however, name which sibling to use instead when the user only wants publication pricing or wants to actually place the order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the link to start an order with Cheap NY Publication for a service, prefilled with the LLC's name when given. Nothing is charged here: the customer reviews the price, agrees to the terms and pays on our secure checkout. Use only when the user says they want to go ahead.
| Name | Required | Description | Default |
|---|---|---|---|
| route | No | Publication only: lower_cost_county (the LLC's county is moved to a lower-cost county) or direct (publish in its own county). Default: whichever costs less. | |
| dos_id | No | The LLC's DOS ID from lookup_new_york_llc, so the checkout opens on that exact record. | |
| service | Yes | ||
| llc_name | No | The LLC's exact name, to prefill the publication checkout. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, idempotentHint and destructiveHint=false; the description corroborates the read-only framing by explaining that no charge occurs, the customer reviews price and terms, and payment happens on a separate secure checkout. That removes the main ambiguity an agent would have about a tool called "start_order" — that calling it commits money. It does not address idempotency or what the link looks like.
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 the return value, then the no-charge clarification, then the usage gate. No filler and each clause adds a distinct fact.
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 correctly tells the agent that the return value is a start-order link, and annotations cover safety. The remaining gap is minor: it doesn't explain what happens with the optional route/dos_id beyond the schema, or whether the link expires.
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 description touches two of the four parameters ("for a service", "prefilled with the LLC's name when given"), usefully signalling that llc_name is optional. Route and dos_id are left entirely to the schema, which already documents them well (75% coverage), so the 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?
States a concrete verb and output ("Returns the link to start an order") for a specific resource (a service with Cheap NY Publication), which clearly separates it from pricing/quote behaviour. It does not name a sibling tool, so an agent must infer the boundary with get_publication_price and quote_llc_formation from context rather than 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?
"Use only when the user says they want to go ahead" gives a clear gating condition and implicitly excludes exploratory/pricing requests. However, it never names the alternatives (get_publication_price, quote_llc_formation) that should be used before this one, so the sequencing is implied rather than spelled out.
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.
start_order2 fields changedInput schema / properties / dos_idAdded value: +{
+ "description": "The LLC's DOS ID from lookup_new_york_llc, so the checkout opens on that exact record.",
+ "maxLength": 32,
+ "type": "string"
+}Input schema / properties / routeAdded value: +{
+ "description": "Publication only: lower_cost_county (the LLC's county is moved to a lower-cost county) or direct (publish in its own county). Default: whichever costs less.",
+ "enum": [
+ "lower_cost_county",
+ "direct"
+ ],
+ "type": "string"
+}get_filing_service1 field changedInput schema / properties / filing_date / descriptionPrevious value: -"Biennial only: the LLC's original filing date (YYYY-MM-DD), to find the due month."New value: +"Biennial only: the LLC's or corporation's original filing date (YYYY-MM-DD), to find the due month."check_llc_name_availabilityexplain_publication_requirementget_filing_serviceget_ny_llc_formation_statisticsget_publication_pricelookup_new_york_llcquote_llc_formationstart_orderUS LLC filing fees, annual-report deadlines and naming-rule checks, from official state sources.
NYC and US property records: owners, LLC officers, mortgages, pre-foreclosures and investors.
Find new business owner contacts the morning the state posts a filing. Preview free, pay per record.
Company formation, registered agents, EINs and annual filings, set out as one brief to quote.
Add one secure layer between your agents and this server.
