New York LLC Publication

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuine value beyond that by disclosing the fallback behavior: returns matching FAQ answers and article links, or a pointer to guides when nothing matches. It does not discuss confidence thresholds or result ranking, 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?

Front-loaded with the purpose, then the topic enumeration, then the exclusions — a logical order with no filler. The topic list is long, but each item earns its place by disambiguating routing; a mild trim would make it a 5.

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, yet the description explains what is returned (FAQ answers, article links, or a pointer to guides), so the agent knows the shape of a success and a no-match result. Combined with explicit sibling exclusions, nothing needed to call 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 coverage is 100% and there is only one parameter, so the baseline is high. The description still adds meaning by enumerating the question categories the parameter should express (solicitation letters, foreign LLCs, theatrical exemption, etc.), effectively constraining what a valid question looks like.

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 (answers) and resource (a specific NY LLC publication question), and enumerates the covered topic space so the agent knows the domain boundary. It explicitly names the sibling tools it is not, making differentiation unambiguous.

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 both sides: the topics this tool is for, and an explicit 'Do NOT use for...' list mapping each excluded case to the correct sibling tool (pricing, county info, process guide, requirements). An agent can route correctly without inspecting other schemas.

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 this as a safe read-only/idempotent tool, and the description adds substantial behavioral scope: statutory sections, consequences of late or missing proof, case law, common misconceptions, and a 'not legal advice' limitation. This tells the agent what the tool will and will not address beyond the safety 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?

The purpose is front-loaded and most content is relevant to an explainer tool, but the description is a dense, run-on paragraph enumerating many statutory details. It could be more scannable with structured bullets, though the excluded-use routing at the end is useful and clear.

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 informational tool with no output schema, the description is complete: it covers scope, legal caveats, edge cases, optional county context, and sibling alternatives. Nothing critical for correct invocation appears to be 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 both optional parameters are already fully documented in the schema. The description mentions county-specific detail and maps LLC categories to statutes, but it does not clarify how the schema's llc_type enum values map to domestic, foreign, and PLLC distinctions, so the baseline of 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 specifically that it explains New York LLC publication requirements, names the relevant statutory sections, and summarizes covered topics. It also distinguishes itself from pricing, county information, and process-guide siblings, so an agent can identify its role 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?

Gives explicit when-not-to-use guidance with named alternatives for pricing, newspaper/clerk lookups, and the step-by-step process. It also notes that county can optionally be supplied for county-specific context, yielding clear routing guidance for the main overlapping siblings.

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 description only needs to add context beyond that. It does: minimum inputs (name, county), that missing details become bracketed placeholders rather than errors, the statutory basis invoked, and a clear "general information, not legal advice" disclaimer. Only omission is any note on output length or formatting details.

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 inputs, then statutory content, then audience, then exclusions — a sensible ordering with no filler. Slightly long, since the enumeration of statutory items and section numbers could be trimmed without losing routing value.

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

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

All six parameters are schema-documented, safety is fully covered by annotations, and there is no output schema — the description fills that gap by describing the return value as template text with placeholders. Nothing an agent needs in order to call or interpret this tool 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 coverage is 100%, so the baseline is 3, but the description adds real meaning: it names the two required inputs and explains that optional details (filing date, service-of-process name/address) are optional because the template substitutes bracketed placeholders. That placeholder behavior is not stated anywhere in 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?

Specific verb plus resource ("Drafts the text of a New York LLC publication notice") with the key output shape stated up front (template with bracketed placeholders). It immediately distinguishes itself from llc_publication_verify_ad_compliance, get_county_pricing and get_process_guide, which do different jobs on the same subject matter.

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 affirmative use cases ("For people preparing their own newspaper submission, or anyone who wants to see what gets published") and explicit exclusions naming three sibling tools for compliance checking, pricing and process guidance. An agent has no ambiguity about routing.

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 openWorldHint=false, so safety is covered. The description adds genuine domain behavior beyond that: the county clerk designates the two newspapers, and in Manhattan/Brooklyn/Queens/the Bronx the clerk assigns newspapers per LLC rather than the list being fixed. It does not say what happens for an unrecognized county name, 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?

Return contents are front-loaded, followed by usage triggers and then exclusions, which is the right order. The borough list appears once as a parenthetical mapping and the NYC assignment rule is restated in the following sentence, a minor redundancy that costs it a point.

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 return values and does so explicitly (newspapers, clerk contact, county mapping). Combined with the full routing guidance and single fully-documented parameter, an agent has everything needed to call this 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% and the parameter description already lists example values, so the baseline is 3. The description earns extra credit by supplying the borough-to-county equivalence mapping (Manhattan=New York County, Brooklyn=Kings, Staten Island=Richmond), which tells the agent what values are semantically valid beyond the schema's examples.

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 a county's publication details") and then enumerates the three return components: newspapers on the Comptroller's list, clerk contact info, and borough-to-county mapping. An agent can distinguish this from every sibling 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?

Gives explicit when-to-use triggers ("which newspapers a county uses, how to reach the county clerk, or which county a borough is") and three explicit exclusions with named alternatives for pricing, requirements, and process steps. This is the strongest possible routing 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/non-destructive/closed-world, so the safety profile is covered for free. The description adds real domain context: the price is a fixed one-time total covering two newspapers, affidavits, and the $50 state fee, and varies by county due to ad rates. It does not say what happens for an unknown county or unfound price, which is the remaining gap.

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 what is returned, then pricing composition, then exclusions. Every sentence carries information an agent would otherwise have to guess; no restatement of the name or 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?

No output schema exists, and the description does not describe the response shape — e.g. whether a single price or a two-county comparison object is returned, or how an invalid county is signaled. Everything else an agent needs to select and call the tool correctly is present.

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% and both parameters are documented in-schema, so baseline 3 applies. The description's note about borough names ('Manhattan', 'Brooklyn') duplicates what the county parameter description already says. The compare_to parameter is only implied by 'two counties side by side' and adds no new syntax 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 and resource ('Returns LLC Publishers' all-inclusive price for New York LLC publication in a county') plus the comparison mode, and explicitly distinguishes itself from three siblings. An agent can identify this tool 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?

Gives explicit when-not rules with named alternatives: requirements → llc_publication_check_requirements, newspaper names/clerk contacts → llc_publication_get_county_info, process steps → llc_publication_get_process_guide. The usage condition (county from the Articles of Organization) is also 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 readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful non-obvious context: that it covers tangential topics (bank account, doing business during publication, Section 206(a) participants) and the disclaimer 'General information, not legal advice.' It doesn't state the return shape (a text guide vs. structured steps), which keeps it below a 5.

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

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

The scope, the situations, and the exclusions are all front-loaded and the exclusions land last where routing decisions are made. It is dense — the form-number enumeration (DOS-1708-f, DOS-1707-f, etc.) is borderline detail — but each clause maps to real content the guide contains, so little is wasted.

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 zero-required-parameter, read-only informational tool with no output schema, the description covers content scope, triggering situations, and exclusions well. The only gap is not characterizing the output (structured step list vs. prose), which an agent might want to know before composing a response.

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 baseline is 3, but the description goes further by mapping the situation enum values to natural-language scenarios ('a new LLC, a foreign LLC, a PLLC, close to the 120-day deadline, or past it') and noting county-specific customization via the county clerk's designation. That gives an agent a reason to supply each optional parameter rather than omit it.

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 resource and verb ('Step-by-step guide to the New York LLC publication process') and enumerates the exact scope it covers: newspaper designation, six weeks of publication, affidavits, the four DOS forms by entity type, fees, and timeline. That level of specificity makes it unmistakable against every sibling 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?

It lists concrete triggering situations (new LLC, foreign LLC, PLLC, close to or past the 120-day deadline) and then explicitly routes the agent away to three named alternatives for pricing, county lookups, and requirements/consequences. This is the strongest form of when-to-use/when-not-to-use 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 readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description goes further, describing the order flow (lookup in NY State records, customer confirmation, cost shown before paying), included items, and an 8-10 week timeline — useful context beyond the annotations, though it omits what the response object actually 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?

Purpose is front-loaded and every clause carries information, but the core content is delivered as one long sentence with a deep nested parenthetical, which makes it denser than necessary. It is efficient in content yet muddy in structure.

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, so the description appropriately enumerates what is returned (ordering process, order form link, inclusions, timeline, county price). For a two-optional-parameter, read-only tool, nothing an agent needs to call or interpret it 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 both parameters are already documented in the schema, making 3 the baseline. The description adds marginal value by noting county yields county-specific pricing when given, but says nothing about the is_foreign parameter or defaults beyond what the schema states.

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 (initiate/return how ordering works) and resource (New York LLC publication ordering via LLC Publishers), and distinguishes itself from siblings by declaring it is not for informational questions. It is clear what the tool yields, though it does not name which sibling handles each alternative case.

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 ('Only use when the person has said they want to order') and when-not ('Do NOT use for informational questions; the other tools answer those'). An agent has an unambiguous routing rule.

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?

Beyond the read-only annotations, it discloses what is checked, what a non-compliant result includes, what corrections may be suggested, and the limits of those suggestions. It also notes the tool is an automated check, not legal advice, which is important behavioral context.

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 front-loaded and every sentence carries useful information, but it is dense and lengthy for a single tool. It remains well structured, with purpose first and exclusions last.

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 absence of an output schema, the description provides enough detail about results, compliance reporting, suggested corrections, entity coverage, and limitations. Nothing critical for correct invocation appears 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 coverage is 100%, so the baseline is 3, but the description adds meaning by linking entity type to the applicable statutory section and explaining foreign LLC-specific checks. It also clarifies that ad_text is an existing notice and llc_name is used for comparison.

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 action: checks an existing publication notice against statutory items by entity type. It clearly distinguishes this verification task from drafting, pricing, and requirements siblings. An agent can identify the tool's role 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 explicitly says when to use it (a notice the person already has) and when not to use it, naming the exact alternative tools for drafting, prices, and requirements. This leaves no ambiguity about routing.

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/closed-world, so the safety bar is met elsewhere; the description adds real value by disclosing the return shape ('a checklist of what is ready and what is missing'), the conditional behavior when llc_name/county/formation_date are supplied (it additionally lists form-to-Filing-Receipt match items), and a scope caveat ('An automated checklist, not legal advice'). It stops short of stating what a partial/empty input yields or whether missing optional params degrade the checklist.

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 terminated by the sibling-exclusion clause, which is the right ordering. The middle enumeration is a single very long run-on sentence packing six checklist items plus three form IDs, which would read faster as a short list, 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 9-parameter, zero-required tool with no output schema, the description covers the essential unknowns: what the return is (a readiness checklist), what triggers the extra form-matching output, and what it explicitly does not cover. The only gap is that all 9 params are optional and the description never says which combination produces a meaningful verdict versus a trivial one.

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 baseline is 3; the description still earns above baseline by tying specific parameters to a document-type table (llc_type → DOS-1708-f domestic / DOS-1707-f foreign / DOS-1709-f PLLC) and by explaining that llc_name, county and formation_date exist to cross-check the form against the Filing Receipt. It does not mention payment_method or expedited, leaving those entirely to 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?

Opens with a specific verb+object: 'Checks whether a Certificate of Publication filing package ... is complete,' then enumerates exactly the document set evaluated (DOS-1708-f/DOS-1707-f/DOS-1709-f, both affidavits, $50 fee, signatures, Department address). The closing sentence names each sibling it is not, so an agent can route without opening another 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?

Explicit negative routing: 'Do NOT use for notice text (use ...verify_ad_compliance or ...generate_ad_text), the process overview (use ...get_process_guide), or requirements (use ...check_requirements).' Each exclusion names the correct replacement. This is the strongest form of 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.