DavisStirling

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so safety is covered. The description adds useful behavioral context: the omission of the parameter returns the full subject-area list, and passing one yields its sections and leading cases. It does not discuss result size or pagination, but the output schema carries the return shape.

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 tightly packed sentences, front-loaded with the use case, then the calling modes, then the exclusion. Every sentence earns its place with no 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 single-optional-parameter browse tool with full annotation coverage and an output schema, this is complete: intent, calling modes, exclusion, and a pointer to the alternative tool are all 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 coverage is 100% for the single optional parameter, so the baseline is 3, but the description goes beyond the schema by explaining the semantic difference between omitting topic (list all subject areas) and providing one (get its sections and leading cases). That is meaning the schema alone does not convey.

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: an overview of an area of HOA law, with concrete examples (board meetings, elections, assessments, records). It is immediately distinguishable from search-based siblings by naming the browsing/overview intent.

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 (user wants an overview or asks what the source covers) and when-not (do not use to answer a specific legal question; use search). It even explains the two calling modes: omit topic to list all areas, pass one to drill into sections and leading 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuine behavioral context beyond that: the shape of returned content per document type and the inclusion of source and currency metadata, which is what an agent needs to trust the result.

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, zero filler; the purpose and returned content are front-loaded before the search exclusion. Every clause 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 single-parameter read tool with an output schema (so return values need not be spelled out) and full annotation coverage, the description says everything needed to select and invoke it correctly: what it returns, which id to pass, and which sibling to use instead when searching.

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 id parameter is already documented with format examples and length bounds. The description adds the provenance of the id ('returned by search'), which is mildly useful but largely restates the schema, so the 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 (read) and resource (full document) scoped by an id from search, and details exactly what content comes back for each document type (statute official text vs. court decision DavisStirling summary plus opinion start). This clearly separates it from the search/get_* siblings without needing their schemas.

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: 'Do not use it to search; use search first to get an id.' Both the when-not condition and the required prerequisite/alternative are named, leaving nothing to inference.

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 cover the safety profile (readOnly, idempotent, closed-world), so the description adds value beyond them: it discloses that results include pre-2014 former numbers via the AB 805 table, that they are ranked by centrality, and that each carries the court's own sentence. The library-coverage limitation is a genuinely useful behavioral caveat.

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 usage trigger before secondary detail about coverage and ranking. No filler; every clause carries information the agent needs.

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 an output schema present, the description need not explain return shape, and it covers the remaining essentials: trigger, former-number inclusion, ranking, and coverage limits. Nothing needed for correct invocation or interpretation 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. The description still adds meaning by explaining that former-number citations are included (directly illuminating the include_former parameter) and that results are centrality-ranked, which contextualizes min_tier. It does not document the section format or limit syntax, keeping it just above baseline.

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 ('which court decisions interpret or apply a Davis-Stirling section'), which is clearly distinct from siblings like get_statute_section (returns the statute) and get_court_case (returns one case). The 'citator' framing sharpens the resource type without ambiguity.

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?

Opens with an explicit trigger ('Use this when the user asks which court decisions interpret or apply a section') and adds a when-not boundary ('Do not use it as a complete citator: it covers only the decisions in this library'). Both the selecting condition and the scope exclusion are stated directly.

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 cover read-only, idempotent, and closed-world behavior, and the description adds real content: what the record contains (court, date, citations, the court's own sentence for cited sections, cases cited) and that the Davis-Stirling summary is 'clearly labeled,' which flags model-generated vs. source text. Pagination via optional opinion text pages is also disclosed.

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 trigger condition before the return payload and the exclusion. The return-value sentence is long and dense, but every clause adds distinct information and none is redundant with the schema.

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?

An output schema exists, so return-value detail is a bonus rather than a requirement, yet the description still characterizes the payload and the labeled summary. Combined with the explicit exclusion and trigger conditions, an agent has everything needed to invoke 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%, so the baseline is 3; the description goes further by mapping what include values yield ('the Davis-Stirling sections the opinion cites (with the court's own sentence)' and 'the cases it cites') and by noting opinion text is optional and paged. It does not mention the offset/max_chars mechanics, but those are documented 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?

States a specific verb and resource ('Get a California HOA court decision') and immediately scopes it to case names, reporter citations, or ids. It also draws a boundary against sibling territory ('Do not use it for statutes or for decisions outside this library'), letting an agent separate it from get_statute_section and resolve_citation.

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 triggers are given ('when the user names or cites a California HOA court decision' or 'you need what a case held') plus a clear exclusion for statutes and out-of-library decisions. It stops short of naming the alternative tool to use instead, so routing is implied rather than spelled out.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds genuine behavioral context beyond annotations: every connection includes the verbatim source text, and results are limited to a fixed set of connection types. It doesn't discuss pagination or result volume, but the added context is substantive.

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 the usage condition, then the return semantics, then the exclusion. No filler; every clause carries 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?

An output schema exists so return values needn't be explained, and the description fully covers purpose, scope, connection types, and usage boundaries. An agent has everything needed to invoke 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 baseline is 3, but the description goes further by explaining in prose what the enum values mean (e.g., 'defined terms it relies on' maps to defines_term, 'procedural steps before and after' to precedes/follows). The limit parameter is not addressed, keeping it below a 5.

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 ('what a section or case is connected to') and enumerates the concrete connection types returned (citations, defined terms, procedural steps, citing cases). It clearly distinguishes itself from siblings like find_interpreting_cases and search by naming the exact relationship classes it covers.

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?

Opens with an explicit when-to-use condition and adds a clear when-not-to-use ('Do not use it to find topically similar law'), which routes the agent to search-style siblings. Both the triggering scenario and the exclusion are stated directly.

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 and determinism are covered. The description adds real behavioral value by enumerating the response payload (text, last amendment, cross-references, defined terms, citing cases) and the closed scope of the corpus, though it adds nothing about limits or error behavior for malformed section numbers.

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 trigger and payload, followed by the exclusion. Zero filler and every clause carries information an agent needs before calling.

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?

An output schema exists, so return-value detail is optional, yet the description still previews the payload. Scope, input formats, optional subdivision behavior, and out-of-scope codes/cases are all covered, leaving no gap an agent would need to fill by guessing.

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 the section and pinpoint formats are already documented in the schema, and the description's accepted-format examples ('4920', '§ 4920(b)(2)', 'Civ. Code § 4920') largely restate them. It adds only the nuance that a single subdivision is optional and read from either field, so baseline 3 is correct.

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 (get) and resource (official text of a Davis-Stirling Act section) with explicit scope: by number, optionally one subdivision, plus amendment, cross-references, defined terms and citing cases. It clearly distinguishes itself from siblings that handle other codes or court cases.

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?

Opens with an explicit 'Use this when you need...' trigger and closes with a hard exclusion: 'Do not use it for other codes (Corporations, Government, Code of Civil Procedure) or for court cases', which routes agents to get_court_case and code-specific siblings. Both when-to-use and when-not-to-use 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, closed-world behavior, so the safety profile is covered. The description adds genuinely new context: it returns the current authority and, for former numbers, where the provision now lives per the AB 805 recodification table. It stops short of describing latency or error/not-found behavior, keeping it just under top marks.

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 with no filler; the usage trigger, accepted inputs, return behavior, and exclusion are all front-loaded. The first sentence is dense with clauses, but every clause carries distinct information, so the density is justified rather than wasteful.

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 a single fully documented parameter, rich annotations, and an output schema covering return values, the description only needed to cover scope, input varieties, and exclusions — and it does all three. Nothing an agent needs to 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 coverage is 100%, so the baseline is 3, and the description earns above that by enumerating accepted input shapes beyond the schema's examples: former pre-2014 numbers like 'Civ. Code 1363' and cases identified by reporter citation or name. That materially expands what an agent knows it can pass.

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 (check/resolve) and resource (California HOA citation) with precise scope: Davis-Stirling sections, former pre-2014 numbers, and cases by reporter citation or name. It clearly distinguishes itself from siblings like get_statute_section, get_court_case, and find_interpreting_cases by virtue of being a citation-resolution 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?

Gives an explicit trigger ('when you need to check a California HOA citation before relying on it') and an explicit exclusion ('Do not use it for citations to other states or other California codes'). This is exactly the when/when-not pattern that routes an agent correctly without opening a schema.

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, openWorldHint=false and destructiveHint=false, so safety is covered. The description goes beyond them by disclosing the exact scope of the corpus searched and the shape of the results (ranked, each with verbatim snippet, citation and link). It omits anything about defaults or ranking behavior, keeping 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?

Three tight sentences: the trigger condition comes first, the scope and return shape second, and the exclusions last. Every sentence earns its place and nothing is redundant 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 annotations covering the safety profile and an output schema covering return values, the description only needs to state purpose, scope, and boundaries — and it does all three. An agent has everything required to select and invoke this 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 description coverage is 100%, so all four parameters (including the kind enum and topic slug) are already documented in the schema, which sets the baseline at 3. The description echoes the statute-versus-case split that maps to the kind enum and mentions citation-style queries, but adds no syntax, format, or interaction detail beyond that.

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 (Searches), a precise resource (the Davis-Stirling Act, Civil Code §§4000–6150, and interpreting court decisions), and the exact corpus boundary. An agent can distinguish this from get_statute_section, find_interpreting_cases, and get_court_case without inspecting 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?

Explicitly gives the when ('user asks about California HOA, condominium or common-interest-development law') and the when-not, enumerating specific exclusions: other states, commercial/industrial CIDs (§§6500–6876), Corporations Code, local ordinances, and a single association's governing documents. This is the full when/when-not/alternative pattern.

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