Skip to main content
Glama

validation_data_integrity

Validate data consistency across CRUD operations by intercepting API responses and comparing data across create, read, update, and delete stages.

Instructions

验证 CRUD 全链路数据一致性。通过 browser_eval 调用 API 并拦截响应,对比 Create/Read/Update/Delete 各阶段的数据是否一致。支持三种验证模式:check_create_read、check_update_read、check_delete_read

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo检测名称,用于报告标识
actionYes验证模式:check_create_read=创建后立即查询验证数据一致性;check_update_read=更新后查询验证字段已更新;check_delete_read=删除后验证已标记删除或 404
entityYes实体名称,如 leads/orders/customers(对应 API 路径中的资源名)
timeoutNoAPI 调用超时时间(毫秒),默认 15000
entityIdNo操作的实体 ID(check_update_read/check_delete_read 时需要提供,或由前一步自动提取)
evidenceNo是否生成证据包,默认 true
noErrorsNo是否检查页面错误,默认 true
targetUrlNo目标页面 URL,用于 API 调用的基础路径
apiBaseUrlNoAPI 基础 URL,默认从当前页面 URL 推导
screenshotNo是否截图,默认失败时截图
createPayloadNo创建操作的请求体(JSON 对象),action=check_create_read 时必填
updatePayloadNo更新操作的请求体(JSON 对象),action=check_update_read 时必填
identifierFieldNo标识字段名(如 id/leadId/orderNo),默认 'id'id
expectedCreateFieldsNo创建后需要验证的字段列表(默认验证 createPayload 中的所有字段)
expectedUpdatedFieldsNo更新后需要验证的字段列表(默认验证 updatePayload 中的所有字段)
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions using browser_eval to intercept responses, but does not clarify whether the tool is read-only, whether it modifies state, or any side effects. Important behavioral traits like permission requirements or destructive potential are omitted.

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 brief with two sentences and a list of modes, front-loading the core purpose. It is efficient though not perfectly structured (no usage example or summary line). The Chinese language may limit accessibility, but conciseness is good.

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

Completeness2/5

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

With 15 parameters, no output schema, and no annotations, the description needs to provide more context. It lacks explanation of return values, preconditions (e.g., browser session), error handling, and how results are structured. The tool appears complex but the description leaves many aspects uncovered.

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?

Schema coverage is 100% with each parameter having a description in the schema. The description lists the three validation modes but does not add meaning beyond what the schema already provides. Baseline 3 is appropriate as the description adds minimal extra semantic value.

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

Purpose4/5

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

The description clearly states the tool's purpose: verifying CRUD data consistency by intercepting API responses via browser_eval. It lists three specific validation modes. However, it does not explicitly differentiate from sibling validation tools like validation_check or validation_flow, leaving some ambiguity about when to choose this tool over others.

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 implies usage contexts through the three modes (check_create_read, check_update_read, check_delete_read) but does not explicitly state when to use this tool versus alternatives among many sibling validation tools. No exclusion criteria or when-not-to-use guidance is provided.

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