Fetch all evidence documents in Drata's evidence library, returning details and versions for SOC 2 audit preparation and compliance monitoring.
List ALL evidence in the evidence library.
Returns evidence documents uploaded to Drata for compliance.
Returns: List of evidence with details and versions
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden; 'List' weakly signals a read-only operation and the text adds useful domain context ('uploaded to Drata for compliance') plus return content. However it says nothing about pagination, result volume, or auth for a tool that returns everything in a library, which are meaningful gaps for a no-annotation 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?
Three short sentences, all front-loaded, with the scope declaration first. Minor overlap between 'evidence in the evidence library' and 'evidence documents uploaded to Drata', but nothing that wastes an agent's attention.
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 need not be explained, and there are no parameters or annotations to cover. The description is nearly complete for this tool; only pagination/volume behavior for a full-library listing is unaddressed.
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?
The schema defines zero parameters, so there is nothing to disambiguate; the baseline for a parameterless tool is 4. The description adds no parameter information, which is appropriate here.
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 (List) and resource (evidence in the evidence library) with an ALL scope qualifier that implicitly contrasts with the filtered sibling list_expiring_evidence. It does not name that sibling outright, so it stops short of a 5-level differentiation.
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 word 'ALL' implies this is the unfiltered enumeration, which hints at when to prefer it over list_expiring_evidence, but no alternative is named and no exclusions, prerequisites, or context are stated. Usage is inferable 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.