Skip to main content
Glama

constraint_validate

Read-onlyIdempotent

Check if a value matches a specified constraint, such as a valid JSON path or integer. Supports partial validation for incomplete inputs.

Instructions

Validate a value against an LMQL-style constraint.

Use this tool to check if a value satisfies a constraint before using it in other operations. Supports partial validation - can tell if an incomplete input could still become valid.

Output contract: Returns {"valid": bool, "error": str?, "is_partial": bool?, ...}. Side effects: None (read-only validation). Failure modes: ToolError if constraint name unknown.

Available constraints:

  • YQ_PATH: Valid yq path (e.g., '.users[0].name')

  • YQ_EXPRESSION: Valid yq expression with pipes (e.g., '.items | length')

  • CONFIG_FORMAT: Valid format ('json', 'yaml', 'toml', 'xml')

  • KEY_PATH: Dot-separated key path (e.g., 'config.database.host')

  • INT: Valid integer

  • JSON_VALUE: Valid JSON syntax

  • FILE_PATH: Valid file path syntax

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYesValue to validate
constraint_nameYesName of the constraint to validate against (e.g., 'YQ_PATH', 'CONFIG_FORMAT', 'INT')

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNo
errorNo
validYes
valueNo
constraintNo
is_partialNo
Behavior5/5

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

Annotations already declare read-only, idempotent, non-destructive behavior. The description adds significant value: explicit side effects (none), failure modes (ToolError for unknown constraint), output contract (valid, error, is_partial), and a comprehensive list of available constraints with examples. No contradictions with annotations.

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 concise and well-structured: purpose, usage guidance, output contract, side effects, failure modes, and constraint list. Every sentence is informative with no redundancy or unnecessary words.

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 the tool's simple validation purpose, the description covers all necessary aspects: when to use, output structure, available constraints, side effects, and failure modes. Annotations safely cover behavioral traits, and the implied output schema complements the description. No gaps for an effective invocation.

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 100% and its parameter descriptions are decent, but the description enriches the constraint_name parameter with a full list of constraints and examples (e.g., 'YQ_PATH: Valid yq path (e.g., ".users[0].name")'). This adds meaning beyond the schema's brief example list.

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 clearly states the tool validates a value against an LMQL-style constraint, with a specific verb and resource. It distinguishes from siblings like constraint_list (which lists constraints) by focusing on validation. The context 'before using it in other operations' further clarifies purpose.

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

Usage Guidelines4/5

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

The description provides explicit guidance on when to use this tool: to check validity before other operations. It also mentions partial validation support. However, it does not explicitly state when not to use it or list alternatives, which would improve differentiation.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bitflight-devops/mcp-json-yaml-toml'

If you have feedback or need assistance with the MCP directory API, please join our Discord server