health
Check Harvey Verify server status, uptime, and payment network configuration.
Input Schema
TableJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
zero-core-verify
Schema Changelog
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
- First observed
TDQS
A3.7/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It implies a read-only check via the verb 'Check', but does not explicitly state safety, permissions, or lack of side effects. It is minimally transparent but lacks explicit behavioral context.
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 a single, focused sentence that conveys the essential purpose without fluff. It is front-loaded with the action and resource, earning a top score for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health-check tool with no parameters and no output schema, the description covers the main aspects. However, it does not explain what the response contains (e.g., status object, error behavior), leaving a gap in the agent's understanding of what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema confirms this with an empty object. The baseline is 4 because no parameter explanation is needed; the description adds no parameter info, which 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 uses a specific verb 'Check' with a clear resource ('Harvey Verify server') and details what is checked (status, uptime, payment network configuration). This clearly distinguishes it from sibling tools like get_service_quality or report_outcome.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention explicit use cases, prerequisites, or exclusions, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Try in Browser
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.