zero-core-verify

verify_outcome

Post-transaction verification. Code checks what it can: the response against expected_schema (a JSON Schema or a list of required field names), and a measured response time against a stated limit. A response that fails code's checks fails without the AI judge; otherwise the judge scores accuracy and completeness as advice. Without a schema or a time limit only the judge decides, and decided_by says so. Returns a verdict (pass, fail or inconclusive), decided_by, scores, format compliance, SLA result, issues, and what code checked.

Input Schema

Name	Required	Description
`service_id`	No	Service identifier for quality tracking (e.g. 'harvey-tools/scrape_url')
`response_data`	Yes	The actual response/output received from the service
`expected_schema`	No	A JSON Schema, or two or more required top-level field names (letters, digits, _ and -) separated by commas, e.g. 'name, price, url'. Anything else is passed to the AI judge only.
`sla_requirements`	No	SLA wording for the AI judge (e.g. 'must include all fields'). For a time limit code can check, use the two fields below.
`request_description`	Yes	What was requested from the service
`sla_max_response_time_ms`	No	The response time limit, in milliseconds
`observed_response_time_ms`	No	The response time you measured, in milliseconds

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedOct 23, 2026

changedInput schema / properties / expected_schema / description

Previous value: -"Expected output format or JSON schema"New value: +"A JSON Schema, or two or more required top-level field names (letters, digits, _ and -) separated by commas, e.g. 'name, price, url'. Anything else is passed to the AI judge only."

addedInput schema / properties / expected_schema / maxLength
```
Added value: +20000
```

addedInput schema / properties / observed_response_time_ms

Added value: +{
+  "description": "The response time you measured, in milliseconds",
+  "maximum": 3600000,
+  "minimum": 0,
+  "type": "integer"
+}

addedInput schema / properties / request_description / maxLength
```
Added value: +8000
```
addedInput schema / properties / response_data / maxLength
```
Added value: +100000
```
addedInput schema / properties / service_id / maxLength
```
Added value: +200
```

addedInput schema / properties / sla_max_response_time_ms

Added value: +{
+  "description": "The response time limit, in milliseconds",
+  "maximum": 3600000,
+  "minimum": 0,
+  "type": "integer"
+}

changedInput schema / properties / sla_requirements / description

Previous value: -"SLA requirements to check against (e.g. 'response under 5s, must include all fields')"New value: +"SLA wording for the AI judge (e.g. 'must include all fields'). For a time limit code can check, use the two fields below."

addedInput schema / properties / sla_requirements / maxLength
```
Added value: +2000
```

First observedApr 30, 2026

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does well: it discloses that code-check failures bypass the judge, that judge scores are advisory, and that decided_by reflects which path was taken. It stops short of stating side effects, persistence, or whether verification results are recorded.

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 front-loaded with the core purpose and remains dense with relevant information. The final sentence enumerates return values, which is justified by the absence of an output schema, though the overall text is somewhat packed.

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?

For a seven-parameter verification tool with no output schema, the description covers the evaluation logic, judge fallback, and returned fields. It does not explain whether results are stored or how this relates to quality tracking implied by service_id, leaving a minor contextual gap.

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 description coverage is 100%, so the schema already documents all seven parameters in detail. The description reinforces expected_schema as either a JSON Schema or a field list and mentions response-time limits, but adds little syntax or meaning beyond what the schema provides.

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 states a specific verb and resource: post-transaction verification of a response against expected_schema and response-time limits, with judge fallback. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools like report_outcome or get_service_quality.

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 explains the conditional logic of when code checks apply versus when only the judge decides, which is useful context. However, it gives no explicit guidance on when to call this tool versus alternatives, and does not mention siblings or exclusion conditions.

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

All zero-core-verify tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

verify_outcome

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources