scf_list_evidence

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

Annotations already declare readOnlyHint=true, so the safety profile is covered and the bar is lowered. The description adds value by disclosing return content (tracking status, maturity level, linked controls) and the optional system filter. It does not mention pagination, result limits, or default behavior when no evidence exists, which are modest gaps for a read-only list 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?

Two sentences with zero filler: the main action is front-loaded, the return fields occupy the second clause, and the optional filter is a short trailing sentence. Every sentence earns its place and the structure is easily scannable.

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 list tool with 2 parameters (1 required), 100% schema coverage, no nested objects, and readOnlyHint=true, the description is close to complete: it states the resource, scope, return fields, and optional filter. The missing elements are pagination/limit behavior and explicit differentiation from sibling list tools, which are minor given the tool's simplicity. A 4 reflects strong but not exhaustive 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 description coverage is 100% — both org_id and system_id carry descriptions in the schema, including useful provenance hints ('obtain from scf_list_organizations' / 'scf_list_systems'). The description merely restates the optional system filter that the schema already conveys, adding no new parameter meaning. Per the rubric, baseline 3 is correct when the schema does the heavy lifting.

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 ('List') with a clear resource ('evidence items') and scoping context ('tracked against an organization's controls'), and it enumerates the return fields (tracking status, maturity level, linked controls). This is clear and actionable, but it never explicitly names its closest siblings (scf_list_evidence_catalog, scf_list_evidence_files, scf_list_evidence_gaps), so differentiation is left to inference 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?

No explicit when-to-use or when-not-to-use guidance is provided and no alternative tools are named. The phrase 'tracked against an organization's controls' implies the operational tracking use case rather than a catalog, gap, or file listing, but with roughly 15 evidence-related siblings, an agent gets no direct routing help. This is implied usage at best.

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