dry-validation

Powerful Ruby validation library from the dry-rb ecosystem — defines validation Contracts with typed schemas (dry-schema) and business rule checks. Unlike ActiveModel validations that mix model and validation concerns, dry-validation creates explicit Contract objects with: a Schema block (coerces and validates types/formats) and Rules block (business logic validations). Returns structured Result objects with typed errors. Works with any Ruby framework (Rails, Hanami, Sinatra). Foundation of Hanami's input validation layer.

Evaluated Mar 06, 2026 (0d ago) v1.x
Homepage ↗ Repo ↗ Developer Tools ruby validation schema dry-rb contract coercion rules form-objects
⚙ Agent Friendliness
68
/ 100
Can an agent use this?
🔒 Security
93
/ 100
Is it safe for agents?
⚡ Reliability
84
/ 100
Does it work consistently?

Score Breakdown

⚙ Agent Friendliness

MCP Quality
--
Documentation
82
Error Messages
88
Auth Simplicity
100
Rate Limits
100

🔒 Security

TLS Enforcement
98
Auth Strength
95
Scope Granularity
90
Dep. Hygiene
88
Secret Handling
92

No network exposure. Strong type coercion reduces injection attack surface. Explicit schema definition enforces input shape. Used as input validation layer before business logic — defense in depth against malformed agent inputs.

⚡ Reliability

Uptime/SLA
85
Version Stability
82
Breaking Changes
78
Error Recovery
90
AF Security Reliability

Best When

You're building Ruby service objects, API endpoints, or form handlers that need explicit type coercion + multi-step validation with structured error reporting, independent of ActiveRecord.

Avoid When

You're doing simple ActiveRecord model validation (Rails validates is sufficient), your team is unfamiliar with dry-rb's functional style, or you're prototyping quickly.

Use Cases

  • Validate agent API request parameters in Ruby backends using dry-validation Contracts — explicit schema coercion + business rule validation with structured error responses
  • Create reusable form validation objects for Rails apps that are testable independently of controllers — validate agent configuration inputs with typed contracts
  • Validate complex nested JSON payloads for agent webhooks using dry-schema's nested hash/array support — validate OpenAI tool call responses or agent event schemas
  • Build service object input validators for agent workflows — Contract classes validate inputs to service objects before executing business logic
  • Generate structured validation errors for API responses — dry-validation returns field-keyed error hashes that map cleanly to JSON API error response format

Not For

  • Simple ActiveRecord model validations — Rails' built-in validates_presence_of/validates_format_of is simpler for basic model validation; dry-validation shines for complex multi-step or API input validation
  • Teams not in dry-rb ecosystem — dry-validation has a learning curve and works best alongside dry-schema, dry-types, and dry-container; isolated use is possible but ecosystem integration adds value
  • Frontend validation — dry-validation is Ruby-only; use Zod (TypeScript) or Joi (JavaScript) for frontend or Node.js API validation

Interface

REST API
No
GraphQL
No
gRPC
No
MCP Server
No
SDK
Yes
Webhooks
No

Authentication

Methods: none
OAuth: No Scopes: No

Validation library — no auth concepts.

Pricing

Model: open_source
Free tier: Yes
Requires CC: No

dry-validation is MIT licensed, maintained by the dry-rb organization. Free for all use.

Agent Metadata

Pagination
none
Idempotent
Full
Retry Guidance
Not documented

Known Gotchas

  • Two-phase validation: Schema runs first, Rules only run if Schema passes — if dry-schema coercion fails (wrong type), rules are skipped entirely; debug schema errors before business rules appear
  • dry-types integration required for type coercion — dry-validation uses dry-types under the hood; custom types require defining dry-types Types module; incompatibility between dry-types versions causes unexpected coercion behavior
  • Macros and rule blocks have different access to schema data — within rule(:field) block, values(:other_field) accesses coerced schema values; raw input not available in rules phase
  • Error message I18n requires configuration — dry-validation uses I18n-style locale files for messages; default messages are generic; custom messages require locale file at config/locales/en.yml with dry_validation key
  • Nested schema validation requires explicit declaration — hash and array schemas inside Contract.schema must use hash.schema and array.each blocks; forgetting these means nested keys pass validation regardless of content
  • Contract inheritance shares schema definitions — subclassing a Contract inherits parent schema; useful for shared base validation but can cause unexpected field inheritance; explicit schema overrides require careful syntax

Alternatives

Full Evaluation Report

Detailed scoring breakdown, competitive positioning, security analysis, and improvement recommendations for dry-validation.

$99

Scores are editorial opinions as of 2026-03-06.

5208
Packages Evaluated
26151
Need Evaluation
173
Need Re-evaluation
Community Powered