ASL Colorado Complaint Access

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds the dependency on the options tool but says nothing about pagination metadata, total result counts, or whether unfiltered calls return the whole directory or a default-scoped subset — the latter matters given the default Active status.

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 short sentences with the capability front-loaded and the prerequisite second, which is the right ordering. No filler, though the filter list partially duplicates what the schema already exposes.

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?

Ten optional parameters, no output schema, and no explanation of the result shape or pagination envelope. The description covers what the tool filters on but not what an agent gets back or how to page through results, which is a meaningful omission for a browsing tool with 10 params.

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 60%, and the description only restates a subset of filters (category, type, status, city, state) that the schema already names. It adds no clarification for name or licenseNumber (exact vs partial match), nor for sort behavior or how filters combine — the gaps the schema leaves open.

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 ('Page through Colorado licensees') and enumerates the filterable dimensions (profession category, license type, status, city, state). It does not distinguish itself from the sibling colorado_license_search, which sounds like an overlapping capability, so an agent cannot fully tell the two apart from the text alone.

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 one concrete prerequisite: call colorado_license_directory_options first for valid categories, types and statuses. That is genuinely useful sequencing guidance, but there is no statement of when to prefer this over colorado_license_search or the SOMB siblings, and no guidance on combining filters.

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, and openWorldHint, so the safety profile is covered. The description adds the scope of what values are returned but says nothing about the return shape (flat lists vs. grouped objects), whether results are static, or how large the sets are, which matters for a zero-parameter reference tool.

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?

A single, front-loaded sentence with no filler. The only weakness is that it is a bare noun phrase without a verb, which reads slightly less directly than 'Returns the ...' would.

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 is the only place an agent can learn what comes back, and it only names the three value groups without indicating structure or format. For a simple zero-arg lookup tool this is adequate, but not fully complete.

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 zero parameters, so the baseline is 4. Nothing in the description misleads about inputs, and no parameter explanation 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 names a concrete resource: the profession categories, license types, and statuses accepted by colorado_license_directory. An agent can tell this is a filter/facet-lookup tool that belongs with the directory sibling. It is a noun phrase with no verb ('list', 'returns'), so the action is implied rather than stated.

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?

Naming colorado_license_directory implies the intended workflow (fetch valid filter values before querying), but the description never explicitly says when to call this versus colorado_license_search, nor that it is a prerequisite for valid filter values. Usage is implied, not 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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the returned fields (status, type, expiry) and the presence of an official verification link, which matters because no output schema exists. It does not mention pagination or what happens on an over-broad name query.

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?

A single sentence that front-loads the resource and search keys, then the return payload. No filler, no restatement of the title, and every clause carries information an agent would otherwise have to guess.

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 search with no output schema, the description covers the return shape and the search modes, which is enough to call it correctly. The one remaining gap is behavioral: with zero required parameters, nothing says whether a bare call with only a city is valid or whether one of name/licenseNumber must be 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 75% and the schema already labels licenseNumber as 'Exact license number' and name as 'Professional or business name', so the description's 'exact license number' phrasing adds little beyond it. It does clarify that city is optional and that name and license number are alternative lookup keys, but the limit parameter is not addressed. Baseline 3 for high schema coverage 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 names a specific verb (Search) and resource (Colorado professional and business licenses, DORA) and enumerates the search keys (licensee name, exact license number, city), so an agent knows exactly what it retrieves. It never references the sibling colorado_license_directory or colorado_license_directory_options, so the boundary between this search and a directory lookup is left implicit.

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 'by licensee name or exact license number, optionally by city' implies the lookup modes and that city is a narrowing filter rather than a sole key, which is useful usage guidance. However, there is no explicit statement of when to pick this over colorado_license_directory, and no statement that at least one of name/licenseNumber should be supplied despite zero required parameters.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral detail that answers come with cited excerpts, but says nothing about behavior when the corpus lacks an answer, whether answers are grounding-only, or any limits on repeated calls.

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 capability and its cited-excerpt output are front-loaded, and the phrasing constraint follows as the actionable secondary point. Nothing repeats the title or 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?

With no output schema, the description correctly supplies the return contract (answers with cited excerpts) and the key input discipline for the required parameter. It would be complete with one line on behavior when the rules do not cover the question, given the openWorldHint flag.

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

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

Schema coverage is 67%, and the undocumented required parameter 'question' is partially rescued by the description's instruction to name the profession, board, or program in it -- guidance the schema does not carry. The 'language' and 'evidenceScope' parameters are already self-documented by enum descriptions, so no further meaning is needed there.

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: answer a question from Colorado DORA board and program rules, plus the return characteristic of cited excerpts. It implicitly separates itself from colorado_somb_standards_ask by naming the DORA board-and-program corpus, but it never names the sibling outright, so an agent must infer the boundary.

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 one concrete usage instruction -- the question must name the profession, board, or program -- which is a real precondition for this tool. It offers no when-not-to-use guidance and no explicit routing against colorado_somb_standards_ask or the license-search siblings, leaving the choice partly implied.

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 annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds no behavior beyond that: no result ordering, no statement of what happens when no filters are supplied, and no pagination behavior. For a 14-parameter search tool this is a missed opportunity.

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?

A single front-loaded sentence with no filler; the resource and its filterable dimensions come first. The trailing filter enumeration is long but each item is informative, so nothing is wasteful—it is simply a dense list rather than a structured breakdown.

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 14 optional parameters, 43% schema coverage, no output schema and several undocumented boolean flags, one sentence is insufficient. The agent is left unsure about default result sets when no filter is passed, pagination via page (undocumented), and the meaning of the exclusion flags, all of which affect how the tool should be called.

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 only 43%, and the description compensates partially by mapping friendly names (name, county, city, ZIP, service, practice level, language, specialty) onto query, county, city, zip, service, practiceLevel, language and specialty. However, it says nothing about the four boolean filters, notably excludeCorrectional and excludePolygraphOnly, which have no schema description either, nor about the undocumented page parameter.

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 uses a specific verb ('Search') on a precisely named resource (the Colorado Sex Offender Management Board approved treatment, evaluation and polygraph provider directory), which is clearly distinct from the license-directory and rules-ask siblings. It stops short of naming any alternative tool or stating the boundary versus a general license lookup, so it lands at 4 rather than 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?

There is no when-to-use or when-not-to-use guidance: nothing tells the agent when to pick this over colorado_license_directory or colorado_somb_standards_ask. The filter list hints at capability but gives no selection criteria, preconditions, or mention that all filters are optional and combinable.

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 this is a read-only, idempotent, non-destructive, open-world operation, so the safety profile is covered. The description adds one useful behavioral detail — answers come 'with cited excerpts' — which tells the agent the response is grounded and attributable. It does not discuss grounding guarantees, coverage limits, or what happens when the standards don't address the question.

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?

A single well-formed sentence with the resource front-loaded and no filler. Every clause (Colorado SOMB, adult or juvenile, cited excerpts) 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?

For a three-parameter question-answering tool with no output schema, the description covers the core purpose and hints at return content via 'cited excerpts.' It is thin on scope boundaries, expected answer behavior, and failure modes, which leaves an agent with limited basis for deciding edge-case usage.

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

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

Schema coverage is 67%, with enum descriptions for language and population and constraints on question. The phrase 'adult or juvenile' reinforces the population parameter's meaning, but the description says nothing about the language option or about what kinds of questions are answerable, leaving the remaining coverage gap partly unaddressed.

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

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

The description names a specific verb ('Answer a question') and resource ('Colorado SOMB adult or juvenile standards and guidelines'), so an agent knows this is a standards Q&A tool rather than a directory or provider lookup. It implicitly contrasts with siblings such as colorado_rules_ask and colorado_somb_providers, though it never names them explicitly.

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 phrasing 'Answer a question from the ... standards,' but there is no explicit statement of when to choose this over colorado_rules_ask or colorado_somb_providers, nor any note on limitations (e.g., what happens for out-of-scope questions). The population scope is left to the parameter rather than stated as guidance.

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