fossa_list_project_revisions

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

With readOnlyHint=true and openWorldHint=true, the safety profile is already covered. The description adds meaningful context by specifying 'analyzed' revisions, which implies the return set is limited to those already processed, and it clarifies the revision locator format. This goes beyond the annotations without contradicting them.

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 sentences, front-loaded with the core purpose, and includes a critical usage note without any wasted words. Every sentence 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?

The tool has 9 parameters and no schema-level descriptions, yet the description only addresses the project_locator. Even with an output schema present, the agent lacks guidance on filtering options (refs_type, source, resolved_only, etc.), making the description insufficient for confident invocation of advanced use cases.

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 9 parameters. The description only hints at project_locator's format ('full revision locator returned by FOSSA'), leaving refs, count, offset, source, minimal, refs_type, resolved_only, and locator_contains completely unexplained. Since the schema itself provides no descriptions, the parameter semantics are largely ambiguous.

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 and resource: 'List analyzed revisions, branches, or tags for a project.' It clearly states what the tool returns and distinguishes it from sibling tools like fossa_list_revision_scans, which focus on scans rather than revisions/branches/tags.

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 description provides clear context on the required input format ('Use the full revision locator returned by FOSSA, including any `$revision` suffix'), which helps the agent construct the project_locator correctly. However, it does not explicitly state when to prefer this over related tools or when not to use it, so it stops short of a 5.

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