Cheap NY Publication: New York LLC filings

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.

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.

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real value beyond that by clarifying this is a combined price-and-explain lookup and by defining the semantics of each service (e.g. the Biennial Statement is the every-two-years report, no annual report). It does not describe the response shape, which slightly limits it.

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 before the enumeration of services, and every sentence carries information (service definitions, the biennial date rule, the scope statement). The long parenthetical enumeration is dense but not redundant; slightly heavy for a three-parameter tool.

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 an informational price-and-explain tool with no output schema and only three params, the description covers what each option means and how to drive the date lookup. The annotations cover the read-only safety profile, so nothing critical is missing, though the returned price/explanation format is left implicit.

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% – filing_date and assumed_name are annotated, but the service enum carries no per-value description in the schema. The description compensates by defining each enum value (Biennial Statement, Certificate of Good Standing/Status, DBA/Assumed Name, county change) and by tying filing_date specifically to the Biennial case.

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 pair (prices and explains) and resource (other New York LLC filings), then enumerates the exact four services covered. It distinguishes itself cleanly from siblings like get_publication_price and quote_llc_formation by scoping to 'other' 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?

'Use for any of these four' plus the per-service explanation tells the agent which enum value maps to which need, and the Biennial Statement sentence explains the extra filing_date input. It stops short of explicitly ruling out sibling tools (e.g. publication pricing), so it is clear context rather than full when/when-not guidance.

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

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.

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

Annotations already establish readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real substance by disclosing the pricing model (Albany county-change route, where the change is filed for the customer, vs. publishing in the LLC's own county) and accepted borough aliases. It stops short of describing rate limits, pricing freshness, or the shape of the returned breakdown.

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 purpose and outcome, then the two pricing routes, then the alternative-tool pointer, which is the right order. It is a bit heavy for three parameters and restates domestic/foreign coverage that the schema already carries.

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?

There is no output schema, so the description carries the return burden and does so by explaining what the price includes and how each route is composed. Combined with annotations covering the safety profile and 100% schema coverage, nothing needed to invoke this 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%, so county, llc_type, and compare_to are already documented with examples and enum semantics; the baseline is 3. The description reinforces llc_type semantics and the purpose of the second county slightly, but adds little syntax or format detail beyond the 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+resource (returns the all-in publication price) scoped to a county and LLC type, and explicitly contrasts itself with the sibling lookup_new_york_llc. An agent can tell it apart from quote_llc_formation and explain_publication_requirement 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 explicit triggers ('Use for any cost question') and an explicit exclusion with the alternative tool named ('If the user names a specific LLC, use lookup_new_york_llc instead'). It also clarifies the optional comparison path, so both the default and extended usage are covered.

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

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.

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.

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: nothing is charged here, the payment happens externally on a secure checkout, and the output is a link rather than a completed order. It does not explain link expiry or reuse, but the annotation set covers idempotency.

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 short sentences, front-loaded with what is returned, followed by the billing clarification and the usage gate. Every sentence earns its place with 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 correctly states what is returned (the order link) and clarifies the no-charge behavior, which is the key thing an agent must convey to a user before invoking. Nothing essential for correct invocation 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 50%: llc_name is documented in the schema, but the service parameter has only an enum with no per-value explanation. The description adds only a generic mention of 'a service' and the llc_name prefill, so it does not compensate for the undocumented enum semantics. 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 states a specific verb and artifact: it returns a link to start an order for a given service, prefilled with the LLC name. This is clearly distinct from siblings that quote or price services (quote_llc_formation, get_publication_price), so an agent can route without opening the 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?

It gives a clear gating condition -- 'Use only when the user says they want to go ahead' -- which separates it from the quoting/price tools. It does not explicitly name an alternative tool to use beforehand (e.g., quote_llc_formation), so it stops short of full when/when-not/alternatives guidance.

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