Skip to main content
Glama

zero-core-verify

by io.github.meltingpixelsai

verify_outcome

Post-transaction verification using LLM-as-judge. Checks if a service delivered what was promised. Returns completeness score, accuracy score, format compliance, SLA adherence, issues list, and overall pass/fail.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
service_idNoService identifier for quality tracking (e.g. 'harvey-tools/scrape_url')
response_dataYesThe actual response/output received from the service
expected_schemaNoExpected output format or JSON schema
sla_requirementsNoSLA requirements to check against (e.g. 'response under 5s, must include all fields')
request_descriptionYesWhat was requested from the service

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4/5.0
Behavior4/5

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

With empty annotations, the description carries the transparency burden. It discloses the LLM-as-judge method and a list of returned metrics, but does not mention side effects, permissions, or read-only behavior.

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

Conciseness5/5

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

The description is two sentences, front-loads the core purpose, and each phrase provides useful information about method and outputs.

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?

The description covers purpose, method, and returned fields, which is important given no output schema. However, it lacks guidance on when to choose it over sibling tools and does not address side effects or prerequisites, making it slightly incomplete for a 5-param tool.

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?

All 5 parameters have schema descriptions (100% coverage), so the baseline is 3. The description mentions metrics like SLA adherence and format compliance, tying to expected_schema and sla_requirements, but adds no additional parameter-level guidance.

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 states a specific action: post-transaction verification using LLM-as-judge, checking if a service delivered what was promised. This clearly distinguishes it from siblings 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 provides implied usage context ('post-transaction') but does not explicitly state when to use this tool over siblings, nor any alternatives or exclusions.

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 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation5/5

Each tool performs a distinct function: health checks server status, list_tools discovers other tools, get_service_quality retrieves aggregated metrics, and report_outcome/verify_outcome record results at different granularities. Descriptions clearly differentiate between simple and detailed outcome reporting.

Naming Consistency4/5

Four tools follow a consistent verb_noun pattern (get_service_quality, list_tools, report_outcome, verify_outcome), but 'health' is a bare noun, breaking the pattern. This slight inconsistency is minor and still readable.

Tool Count5/5

With 5 tools, the server is well-scoped for verification tasks: system health check, tool discovery, aggregated quality retrieval, and two outcome recording methods. Each tool has a clear purpose without redundancy.

Completeness4/5

The tool set covers core verification workflows: recording outcomes and retrieving aggregated quality. However, lacking a tool to retrieve individual verification records or list services creates minor gaps that agents might work around.

Resources