Skip to main content
Glama

Validate document content

validate

Check system specification document content for whole-body domains without disk or ID access. Verify body-only content or complete frontmatter plus body, returning a boolean and error messages.

Instructions

Disk-free, id-free dry run validating document content across the whole-body domains (type is one of req, uc, tsk, qa, prb, gol, rsk, dec, sop, feat, vcr, sysrs; adr is not supported -- use validate_adr instead). full=False (default) validates body-only content (no frontmatter); full=True validates a complete document (frontmatter + body). Never raises for a content-validation failure: always returns {valid: bool, errors: list[{message: str}]} -- errors is empty when valid is True, and each message is truncated to at most _MAX_VALIDATE_ERROR_CHARS (300) characters (plus an "... (truncated)" suffix when truncation occurred) rather than returned verbatim without limit. A full/content-shape mismatch, or an unsupported type, is a caller-usage error and still raises ValueError before any validation runs. This is the sole validate entry point for these domains -- the former per-domain validate_<d> tools are removed; validate_adr remains a separate, unchanged, id-based tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fullNo
typeYes
contentYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
validYes
errorsYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.36.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are present, so the description carries the full behavioral burden and does so well: it discloses that content-validation failures never raise, the exact return shape ({valid, errors}), that errors is empty on success, and the 300-char truncation with suffix. It also states precisely when ValueError IS raised (full/content-shape mismatch or unsupported type) before validation runs.

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?

Front-loaded with purpose and alternative routing, then detail. It is dense and a few parentheticals (the truncation mechanics, the _MAX_VALIDATE_ERROR_CHARS reference) run long, but nearly every clause carries information an agent needs.

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

Completeness5/5

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

Given an output schema exists, return values need not be spelled out, yet the description still clarifies them. Combined with the error/exception boundary and domain coverage, an agent has everything required to call it correctly without opening other tools.

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?

Schema coverage is 0%, so the description must compensate, and it does for `full` (default body-only vs complete document) and `type` (enumerates domain semantics and the adr exclusion). `content` is left implicitly understood as the document text, which is the only minor gap in an otherwise strong compensation.

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?

States a specific verb and resource ('dry run validating document content'), names the supported domains, and explicitly distinguishes itself from both the removed per-domain tools and the still-separate validate_adr. An agent can immediately tell this is the single entry point for body-content validation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent: adr is unsupported here and directs to validate_adr, and it explains the full=False body-only vs full=True frontmatter+body choice. The 'sole validate entry point for these domains' note removes any ambiguity about redundancy with siblings.

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