FilingDesk Data

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

Beyond the readOnlyHint annotation, the description discloses that a verdict is an indication, never a reservation, and that the note and verifyUrl must be shown. It also explains state-specific behaviors, adding meaningful context for the agent without contradicting 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 description is two sentences, front-loaded with purpose, then concise caveats about state coverage and legal status. Every word earns its place.

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 simple lookup tool with no output schema, the description fully explains state-specific outcomes, what to return, and the non-reservation caveat. It covers all necessary context for correct invocation and response handling.

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. The description adds no extra parameter meaning beyond what the schema already documents; it only references state behavior in prose.

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 clearly states the tool checks a proposed business name against a state's live registry, which is a specific verb+resource. It distinguishes from siblings by focusing on name availability, not formation, fees, or deadlines.

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 gives clear context on state support (real results for WY/DE, Florida link-only, others unsupported) and instructs to always show the returned note and verifyUrl. It does not explicitly name alternatives, but none of the sibling tools offer this functionality.

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 only provide readOnlyHint=true, but the description adds critical behavioral guidance: returns fixed comparative facts, includes a required disclaimer, must be presented neutrally, and a human specialist confirms before filing. This goes well beyond the annotation.

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 main purpose and followed by actionable usage instructions. No fluff or repetition; every sentence earns its place.

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 adequately conveys return type (fixed comparative facts and disclaimer) and the overall process (neutral presentation, specialist confirmation). Combined with good schema descriptions and readOnly annotation, the description is complete for this decision-support tool.

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 well-described in the schema (topic enum with meanings, homeState with what it does). The tool description itself adds no additional parameter semantics, so 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?

Description clearly states the tool's purpose: to provide factual tradeoffs for deciding where to form or what entity type to pick. It distinguishes itself from siblings like compare_llc_costs by covering both state and entity type options, not just costs.

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 says when to use: when someone needs to decide WHERE to form or WHAT entity type to pick. It also gives when-not: deliberately NOT a recommendation, and that FilingDesk specialist confirms before filing, setting clear boundaries and usage context.

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 include readOnlyHint=true, so no need to restate safety. The description adds value by clarifying exactly what 'cost' means (one-time formation, recurring, combined first-year), which is not obvious from the tool name alone. No contradictions with 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 description is two sentences, front-loaded with the core action ('Rank states'), and every clause contributes meaning. No fluff or repetition of schema details.

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 simple read-only comparison tool with 100% schema coverage and no output schema, the description covers the essential use case, what it compares, and how to use it. It could mention the output format (e.g., a ranked list) but 'Rank states' implies that. Overall, it is complete enough for the tool's complexity.

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 fully documents all three parameters. The description does not add additional parameter-level semantics beyond what is already in the schema; it only hints at the sort criteria conceptually. 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 clearly states the tool's function: 'Rank states by what an LLC actually costs.' It specifies the resource (LLC costs across states) and the specific comparisons made (formation fee, recurring cost, first-year total), distinguishing it from siblings like get_llc_fees or compare_formation_options.

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 explicitly provides usage context: 'Use this for cheapest state to form an LLC style questions rather than guessing.' This gives clear guidance on when to use the tool, though it does not mention alternative sibling tools or explicit exclusions beyond 'rather than guessing.'

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, and the description adds a useful behavioral detail: the tool will not guess a date when formationDate is missing for affected states. This goes beyond the annotation by explaining the tool's fallback behavior.

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 main purpose and a conditional nuance, with zero waste. Every word earns its place.

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?

Despite lacking an output schema, the description specifies exactly what the tool computes (due date, amount, penalty) and the behavior when formationDate is omitted. This is complete for a simple read-only tool with strong schema coverage.

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%, with both state and formationDate already described. The description restates that formationDate is required for certain states, which is already in the schema, so it adds little new parameter-level meaning beyond the structured fields.

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 opens with 'Work out when a state's annual report or franchise tax is next due, the amount owed, and the late penalty,' clearly stating the specific verb, resource, and scope. It distinguishes itself from siblings like get_llc_fees or check_llc_name by focusing on deadlines and penalties.

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 clear context: formationDate is required for anniversary- or quarter-based states, and the tool explicitly says so rather than guessing. It doesn't explicitly name alternatives, but the purpose is distinct enough that the usage context is evident.

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?

The description adds useful behavioral context beyond the readOnlyHint annotation: it specifies that each data point includes a source URL, and mentions 'known gotchas' which are not obvious from the tool name or schema. This helps the agent anticipate the richness and reliability of the response.

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 a single, information-dense sentence. It lists all key output components (fee, cost, processing time, gotchas, source URLs) without unnecessary words. The title is clear and the description is front-loaded with the most important 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?

For a simple one-parameter tool with no output schema, the description fully conveys what the agent should expect: multiple fee-related data points with source URLs. It covers scope (all 50 states + DC) and data types, making it complete for its complexity level.

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 explains the state format and scope. The tool description adds no additional parameter-level detail beyond reinforcing that it covers all 50 states + DC, which is already present in 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?

The description clearly states the tool's purpose: to provide official LLC formation fees, recurring annual-report/franchise-tax costs, processing time, and gotchas for a single US state. It distinguishes itself from siblings by specifying 'single US state' and enumerating the data returned, which differs from comparison or deadline-specific 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?

The description clearly indicates when to use this tool: when you need fee-related information for one specific state. It implies that for multi-state comparisons, other tools like compare_llc_costs would be appropriate, though it doesn't explicitly name alternatives. Sibling names are visible to the agent, providing additional context.

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?

The annotation readOnlyHint=true already indicates a safe read-only operation, and the description adds valuable context beyond this by enumerating the specific data categories returned (state filing status, name-checking capability, fee/deadline coverage). This tells the agent what to expect from the output without needing an output schema. It does not overpromise or contradict the annotation.

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 compact and front-loaded: the first sentence lists the content categories, and the second sentence gives a clear usage instruction. Every word earns its place with no redundancy or filler. It is an efficient two-sentence description that covers purpose and usage.

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 that there is no output schema and no parameters, the description takes on the responsibility of explaining what the tool returns. It does so by listing three specific content areas (state filing, name-checking, fee/deadline coverage), which is sufficient for a simple list tool. It could be more explicit about the response format, but the essential information is present for an agent to decide when to call it.

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?

There are no parameters in the input schema, so the baseline score is 4. The description correctly focuses on the tool's behavior rather than parameter details, since there are none to explain. No additional semantic guidance is needed.

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 clearly states the tool's purpose: to list FilingDesk's per-state capabilities, including filing coverage, name-checking, and fee/deadline data coverage. It distinguishes itself from sibling tools by focusing on state coverage rather than individual checks or comparisons. The verb is implicit in the tool name but the description fully explains what information is provided.

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 explicitly instructs to call this tool before telling a user FilingDesk can file somewhere, providing a clear usage trigger. It does not mention alternatives or exclusions, but the sibling tools (e.g., check_llc_name, get_llc_fees) serve distinct purposes, making the context unambiguous. The 'Call this before' guidance is an explicit when-to-use directive.

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?

The annotation readOnlyHint=true already establishes a safe read operation. The description builds on this by explaining the tool validates details, prices the order, and returns a confirmation summary, which goes beyond the annotation. It does not disclose error handling or rate limits, but for a read-only preview tool, the added behavioral context is valuable and consistent.

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 three sentences, front-loaded with the core purpose, immediately noting no submission, and ending with a clear mandatory usage directive. Every sentence earns its place without redundancy or fluff.

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?

The tool is relatively simple, the schema is thorough, and the description explains the return (a confirmation summary) and the required usage pattern. While no output schema exists, the description provides enough context for an agent to know when to call it and what to expect, though the exact structure of the summary is unspecified.

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 input schema covers all 7 parameters with detailed descriptions, including accepted formats (e.g., state as 'WY' or 'Wyoming') and nuances (e.g., entityType includes 'Not sure'). The tool description does not add parameter-level detail, but with 100% schema coverage, 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?

The description clearly states the tool builds an exact order summary without submitting, using specific verbs like 'validates', 'prices', and 'returns'. It explicitly contrasts with submit_order by saying 'WITHOUT submitting anything', making the tool's purpose unambiguous and distinct from its primary sibling.

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 an explicit directive: 'ALWAYS call this and show the user the returned summary before calling submit_order'. This offers precise when-to-use guidance relative to the main alternative, and the 'No side effects' statement reinforces safe use cases.

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?

The description goes well beyond annotations by explaining the real-world effect: creates an order, notifies a specialist, nothing charged now, and a payment link is emailed later. It also mentions the return of the order reference. These behavioral details are not present in the annotations, which only state readOnlyHint=false and openWorldHint=true.

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 compact and front-loaded with purpose. It contains five sentences, each adding value, though the capitalized 'THIS HAS A REAL-WORLD EFFECT' is slightly embellished. Overall, it is well-structured for the complexity.

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?

The description is complete for a side-effectful tool: it covers when to call, the real-world impact, the subsequent review process, and the return value (order reference). Even without an output schema, the agent has enough context to invoke the tool 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 parameter descriptions are detailed. The description adds no additional parameter semantics beyond what the schema provides, 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?

The description clearly states the tool submits a real formation order to FilingDesk, with a specific verb and resource. It distinguishes itself from sibling tools like preview_order by noting it should be called after preview_order and by emphasizing the real-world effect.

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 usage guidance is provided: 'Only call after preview_order and after the user has explicitly confirmed the summary.' This clearly dictates when to use the tool versus alternatives, and the sequencing with preview_order is highlighted.

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