1Court Directory

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

The description adds substantial behavior beyond the annotations: it discloses deterministic calculation, application of weekends, legal holidays, short-period and mail-service rules, and the returned date, computation steps, rule text and source. It also adds an important legal caveat. This is consistent with the read-only and closed-world 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 definition is two tightly written sentences with the core purpose front-loaded. Every sentence contributes useful information, and the caveat is placed at the end where it is easy to retain.

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 six parameters, full schema descriptions, and no output schema, the description is complete enough for an agent to call the tool correctly. It explains the return content and caveats, while the schema handles parameter-level detail.

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 input schema already documents all six parameters thoroughly. The description adds context about rule application but does not explain parameter meanings or formats beyond what the schema provides.

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 resource: calculate a court deadline deterministically from cited rules. It also names the rule categories applied, making the tool's function clear. It does not explicitly differentiate itself from sibling lookup tools, so it falls short of a 5.

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 purpose implies when to use the tool, but there is no explicit routing to `list_deadline_rules` for obtaining a valid `deadline_type`, nor any when-not-to-use guidance. The instruction to show citations and caveats concerns output handling rather than tool selection.

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 and openWorldHint=false, so safety is covered; the description adds genuinely new context by stating the data is sourced from official court/clerk records and imposing an output obligation ('Always cite the returned 1Court source URL'). It does not say how the tool behaves when the county is not covered or not found.

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 core action and then a dense but purposeful enumeration of the returned data categories. The citation rule is placed last, where it reads as a usage condition rather than being buried mid-sentence.

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 compensates by listing the data categories the caller will receive and the citation requirement on the returned source URL. The remaining gap is failure/coverage behavior for counties outside the dataset, which matters for a lookup keyed on free-text county names.

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%, including accepted formats for state ('Texas', 'TX') and county ('Harris', 'Harris County'), so the schema carries the parameter burden. The description adds only the scoping fact that the county must be a U.S. county, which is marginal beyond what the schema already 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?

States a specific verb and resource ('Get verified court information') and enumerates exactly what is returned: clerk contacts, e-filing provider, fees, case lookup, self-help, jury service, payment links. This makes it immediately distinguishable from list_counties, list_states, and search_courts, which are enumerations rather than per-county detail lookups.

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 phrase 'for a specific U.S. county' plus the required state/county pair makes it clear this is a single-record lookup rather than a browse or search operation, implicitly routing the agent away from the list_* siblings. It stops short of naming search_courts as the alternative when the county is unknown.

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 openWorldHint=false, so safety is covered. The description adds value beyond that by describing the return payload ('each county name and its 1Court page URL'), which matters because no output schema exists.

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 tightly packed clauses: the operation first, then the accepted input formats and the return shape in parentheses. Nothing is wasted and the key information is front-loaded.

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 one-parameter, non-paginated lookup, the description covers input formats and return contents, which is enough to call it correctly. Minor gaps (error behavior for an unknown state, ordering of results) are low-stakes here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single 'state' parameter already documents name, 2-letter code, and slug with examples. The description repeats the same accepted formats but adds no new syntax or edge-case guidance, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List'), a specific resource ('counties'), and the scope ('in a given U.S. state'). An agent can distinguish this from list_states and search_courts 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?

Usage is implied by the scope — call it when you need the counties of a known state — but there is no explicit when-to-use/when-not or reference to the sibling tools (list_states, get_court_info) that an agent might otherwise pick.

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 openWorldHint=false, so safety is covered; the description adds the return contract ('Returns each deadline with the governing rule citation for each') and the local-rule augmentation behavior. It does not mention permissions, rate limits, or result size, 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?

Front-loaded with the purpose and the workflow instruction before the long id enumeration, so the agent gets the essentials first. The parenthetical catalog of ids is heavy and partly repeats the state parameter's schema description, which is the main efficiency cost.

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 describing the return values is necessary and is done here; the description also covers all three parameters' roles and the workflow dependency. For a read-only listing tool with full schema coverage, nothing an agent needs to call 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 coverage is 100%, so the baseline is 3, but the description adds real meaning by expanding what ambiguous ids mean (CA-PRESUIT, CA-AGENCY, CA-SPECIAL) so the agent can choose the right rule set rather than guessing from an opaque acronym. It also clarifies the county/court formats, though this partly duplicates the schema text.

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 ('List the court deadline types') and immediately bounds the scope ('1Court can calculate for a jurisdiction'), which separates it from calculate_deadline and the court-lookup siblings. An agent can identify the tool's output 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?

Explicitly routes the agent: 'Use before calculate_deadline to get valid deadline_type ids', establishing both sequencing and the downstream consumer of the result. It also gives the conditional rule for local rules (add county or court), so the agent knows which optional params to supply and when.

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 openWorldHint=false, so safety and closed-world scope are covered structurally. The description adds value by disclosing that results are limited to covered states and include per-state county counts, which tells the agent what it will actually receive. No pagination or ordering detail, but the set is inherently small.

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, no filler: the first defines what is returned, the second defines when to call it. The high-value usage cue is front-loadable and present without redundancy.

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

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

For a no-parameter, read-only discovery tool with no output schema, the description covers everything an agent needs: what is returned (states plus county counts), the domain boundary (1Court Directory coverage), and the intended next step. Nothing required 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?

Zero parameters, so there is nothing for the description to compensate for; the baseline for a 0-param tool is 4. The description correctly does not invent any input semantics.

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 ('List all U.S. states covered by the 1Court Directory') plus the payload ('how many counties are available in each'). The scope distinguishes it clearly from siblings like list_counties and search_courts, which operate at a finer granularity.

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 'Use this to discover coverage before looking up a specific county,' which gives a clear entry-point role relative to list_counties. It stops short of naming the sibling tools or stating exclusions, so it's a strong but not exhaustive usage statement.

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 readOnlyHint=true and openWorldHint=false. The description adds meaningful behavioral context by saying the tool returns matching counties with their 1Court page URLs, which is important because no output schema exists. It still does not explain matching behavior, multiple-result handling, or limits.

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 tight sentences with no filler. The core search behavior and return value are front-loaded, followed by a concise usage note.

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 search tool with full schema coverage and safety annotations, the description covers purpose, usage context, and return content. It is nearly complete, though it could say more about how fuzzy matching works or how multiple matches are returned.

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 the single query parameter is already documented with examples such as 'Maricopa', 'Cook County', and 'Nevada.' The description reinforces that the query is a county or state name but adds no syntax or format guidance 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?

The description states a specific verb and resource: 'Search the 1Court Directory by county or state name' and explains the result as 'matching counties with their 1Court page URLs.' It is clear but does not explicitly contrast itself with siblings like list_counties, list_states, or get_court_info.

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 provides a clear usage condition: 'Use when you are unsure of the exact county or state format.' However, it does not name alternatives or state when not to use the tool, so it falls short of 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.