Retrieve metadata for evidence captured under a work ID, enabling addressable access to contents by evidence ID.
List evidence captured by the runtime. Metadata only: contents are addressable by evidence ID.
| Name | Required | Description | Default |
|---|---|---|---|
| workId | No |
Changes observed during successful MCP inspections.
v0.2.18Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true, and the description adds value by stating 'Metadata only' and 'addressable by evidence ID', which clarifies the return nature and how to access content later. No contradiction exists.
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 the core purpose front-loaded and no extraneous words. Each sentence earns its place, providing essential information efficiently.
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 description covers the tool's primary function and metadata nature, but leaves the workId parameter unexplained and omits any details about the output format. Given the tool's simplicity, it is partially complete but not fully self-sufficient.
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 optional 'workId' parameter is not explained anywhere in the description. With 0% schema coverage, the agent has no indication of its purpose or effect, making it a significant gap.
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 states a specific verb ('List') and resource ('evidence captured by the runtime'), and clarifies the metadata-only scope. This distinguishes it from other listing tools by focusing on evidence, so an agent can easily identify its purpose.
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 metadata-only note implies that actual content requires another tool, but no explicit alternative or condition is mentioned. Usage is inferred rather than prescribed, with no guidance on when to prefer this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.