Validates document against schema (JSON Schema draft-07 or 2020-12). Reports one specific violation per call, not an aggregated list.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | Yes | a JSON Schema (draft-07 or 2020-12) | |
| document | Yes | the JSON value to validate against schema |
| Name | Required | Description | Default |
|---|---|---|---|
| valid | Yes | ||
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden of behavioral disclosure. It discloses that the tool returns one violation per call, which is a key behavioral trait. However, it does not state whether the operation is read-only, has side effects, or requires authentication. Since validation is typically side-effect-free, the lack of explicit mention is a minor gap. With an output schema present, return format details are not required, but the description could be more transparent about the nature of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences. The first sentence establishes the core purpose, and the second adds a critical behavioral detail. Every word is purposeful; there is no redundancy or fluff. The structure is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, output schema exists), the description is largely complete. It covers the purpose and a key behavioral trait (one violation per call). The output schema likely handles return value details. The description could mention that the tool is read-only or that it expects a well-formed schema, but these are reasonable assumptions. Overall, it provides sufficient context for appropriate use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers both parameters with descriptions, achieving 100% coverage. The description adds little beyond the schema: 'a JSON Schema (draft-07 or 2020-12)' for 'schema' and 'the JSON value to validate against schema' for 'document' are clear but not significantly enriched. Baseline 3 is appropriate as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Validates document against schema (JSON Schema draft-07 or 2020-12).' This specifies the verb (validates), resource (document against schema), and scope (specific schema versions). The tool is distinct from siblings like email_validate, regex_match, and url_validate, which are format-specific validators. The additional behavioral note about reporting one violation per call further refines the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It provides a behavioral nuance ('Reports one specific violation per call, not an aggregated list'), which implies that for complete validation, multiple calls may be needed. However, it does not mention that for format-specific validation (e.g., email, regex, URL), sibling tools should be used. The usage context is implied but not explicitly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct validation domain: email, URL, regex, and JSON schema. There is no overlap; an agent can clearly distinguish which tool to use for a given validation task.
All tools follow a consistent verb_noun snake_case pattern (e.g., email_validate, url_validate). The use of 'match' for regex is a minor variation but still fits the pattern, and overall naming is predictable.
Four tools is a well-scoped number for a validation utility server. It covers the main advertised domains without being bloated or too sparse.
The server covers its named areas (regex, email, URL) and adds JSON schema validation. Missing a generic string pattern validator or phone number validator, but the scope is sufficiently covered for common use cases.