Skip to main content
Glama

evidence

Generate evidence packages with screenshots, DOM, errors, and network data for each step, or build verification timelines by indexing evidence files across runs.

Instructions

证据管理工具(v1.9.5 起合并 evidence_pack/evidence_index)。通过 mode 参数区分子模式:pack(默认,生成单步证据包,把截图、DOM 摘要、错误、网络请求、API 响应摘要、数据 diff、traceId、Console、PageError、HAR 汇总成一个 JSON 文件)/ index(证据包索引,扫描 reports 目录所有 evidence.json 文件,按 runId 串联生成完整验证时间线)。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
harNo是否导出 HAR,默认 false(mode=pack 时使用)
modeNo工作模式:pack(默认,生成单步证据包)/ index(证据包索引与时间线)pack
labelNo步骤名称,stepId 未传时作为 stepId(mode=pack 时使用)
runIdNo本次验证运行 ID,不传则自动生成(mode=pack 时使用);mode=index 时可选,只返回指定 runId 的证据包时间线
stepIdNo当前步骤 ID,如 marketplace.purchase.after-click(mode=pack 时使用)
traceIdNo可选链路追踪 ID,用于和后端日志关联(mode=pack 时使用)
snapshotNo是否采集 DOM 简要快照,默认 true(mode=pack 时使用)
afterDataNo操作后数据快照,用于生成 data diff(mode=pack 时使用)
afterStateNo操作后状态快照引用(mode=pack 时使用)
beforeDataNo操作前数据快照,用于生成 data diff(mode=pack 时使用)
screenshotNo是否截图,默认 true(mode=pack 时使用)
autoAnalyzeNo截图后是否自动分析可见错误,默认 true(mode=pack 时使用)
beforeStateNo操作前状态快照引用(mode=pack 时使用)
captureStepNo是否同时调用 browser_step 采集截图和 DOM,默认 true(mode=pack 时使用)
currentOnlyNo是否只采集当前 checkpoint 后的错误和网络,默认 true(mode=pack 时使用)
consoleLimitNo证据包中保留最近 Console 条数,默认 30(mode=pack 时使用)
networkLimitNo证据包中保留最近网络请求条数,默认 30(mode=pack 时使用)
pageErrorLimitNo证据包中保留最近 PageError 条数,默认 10(mode=pack 时使用)
includeTraceIdsNo是否在结果中包含所有 traceId 列表,默认 false(mode=index 时使用)
includeWarningsNo错误摘要是否包含 warning,默认 false(mode=pack 时使用)
apiResponseLimitNo证据包中保留最近 API 响应摘要数,默认 10(mode=pack 时使用)
Behavior3/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It explains that pack mode generates a JSON file summarizing various evidence types, and index mode scans directories. However, it does not mention side effects like file creation, permissions needed, or potential rate limits. The description gives a reasonable overview but omits important implementation details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured, starting with a version note, then explaining the two modes and their outputs. Every sentence adds value. It could be slightly shorter, but it efficiently conveys the essential information for a complex tool with 21 parameters.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (two modes, many parameters, no output schema), the description provides a reasonably complete overview. It explains what each mode produces (JSON file contents, timeline). It could mention file system interaction or error handling, but overall it covers the key aspects sufficiently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 100% description coverage, providing adequate per-parameter info. The tool description adds context by grouping parameters under modes and explaining the overall purpose, but it does not add significant extra meaning beyond the schema descriptions. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states it is an evidence management tool that merges evidence_pack and evidence_index since v1.9.5. It clearly defines two sub-modes (pack and index) with distinct responsibilities: generating single-step evidence packages vs. indexing for a timeline. This distinguishes it from sibling tools like browser_* tools and even the deprecated individual evidence tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides indirect usage guidance by defining the mode parameter and explaining what each mode does. However, it does not explicitly state when to use this tool vs. the deprecated evidence_pack/evidence_index siblings, nor does it mention when not to use it. The guidance is adequate for mode selection but lacks explicit alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/validpilot/ai-verify-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server