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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: results are returned without exposing private storage credentials, implying credential-free metadata rather than raw storage access. It does not say whether items are paginated, what fields each entry has, or whether permissions are required.

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?

One short sentence with the resource front-loaded and no filler. The trailing credential clause earns its place as the only behavioral detail, though it is phrased more like a security assurance than an operational fact.

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 read-only list tool with full annotation coverage and an output schema that documents the return shape, nothing essential is missing. Pagination and permission notes would be nice, but the structured fields already carry the bulk of the contract.

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 0% for the single required jobId, so the schema supplies no meaning. The description partially compensates by framing the operation as scoped to a job, which implies jobId identifies that job, but it adds no format, sourcing, or validation detail for the 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?

States a specific verb ('Lists') and resource ('job photos and files'), scoped implicitly to a single job via the jobId parameter. It is distinguishable from write-side siblings like attach_job_file or prepare_job_evidence_upload, though it never explicitly contrasts with them or with get_job.

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 guidance, no prerequisites, and no named alternative for retrieving file information (e.g., versus get_job or attach_job_file). The agent must infer from the name alone that this is the read path for a job's file list.

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