Structured Data Validator & Transformer MCP Server
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Structured Data Validator & Transformer MCP ServerValidate this JSON against the user schema"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Structured Data Validator & Transformer MCP Server
A professional-grade MCP server that provides AI agents with powerful data validation, transformation, and normalization capabilities. Built specifically for the agent economy by Agenson Horrowitz.
๐ค Why This Exists
AI agents constantly deal with messy, inconsistent data from APIs, web scraping, user uploads, and other agents. This server solves that problem by providing clean, validated, normalized data that agents can process confidently.
Related MCP server: DataBeak
โก Key Features
JSON Schema Validation: Validate any data against JSON schemas with detailed error reporting
Intelligent CSV Processing: Convert CSV to JSON with auto-type inference and flexible parsing
Data Normalization: Standardize dates, phone numbers, currencies, and email addresses
Text Cleaning: Remove HTML, fix encoding issues, normalize whitespace
Dataset Merging: Combine multiple datasets with smart conflict resolution
Built for Speed: Sub-2-second response times for typical agent workloads
Error Resilient: Graceful handling of malformed data with detailed error messages
๐ Installation
Claude Desktop Configuration
Add to your claude_desktop_config.json:
{
"mcpServers": {
"structured-data-validator": {
"command": "npx",
"args": ["@agenson-horrowitz/structured-data-validator-mcp"]
}
}
}Cline Configuration
Add to your Cline MCP settings:
{
"mcpServers": {
"structured-data-validator": {
"command": "npx",
"args": ["@agenson-horrowitz/structured-data-validator-mcp"]
}
}
}Via npm
npm install -g @agenson-horrowitz/structured-data-validator-mcpVia MCPize (One-click deployment)
Deploy instantly on MCPize with built-in billing and authentication.
๐ ๏ธ Available Tools
1. validate_json_schema
Validate JSON data against any schema with comprehensive error reporting.
Use cases:
Validate API responses before processing
Ensure user input matches expected format
Verify data integrity across agent workflows
Example:
{
"data": {"name": "John", "age": "not-a-number"},
"schema": {
"type": "object",
"properties": {
"name": {"type": "string"},
"age": {"type": "number"}
},
"required": ["name", "age"]
}
}2. transform_csv_to_json
Convert CSV data to structured JSON with intelligent type inference.
Features:
Auto-detects delimiters (comma, semicolon, tab, pipe)
Infers data types (numbers, dates, booleans)
Handles headers automatically
Cleans messy data during conversion
Example:
{
"csv_data": "name,age,active\\nJohn,25,true\\nJane,30,false",
"options": {
"infer_types": true,
"has_headers": true
}
}3. normalize_data
Standardize common data formats across your datasets.
Supported formats:
Dates: Any format โ ISO 8601 or custom format
Phone Numbers: Any format โ International format
Currencies: Any format โ Standardized currency notation
Email Addresses: Validation and normalization
Example:
{
"data": [
{"name": "John", "phone": "(555) 123-4567", "date": "12/25/2023"}
],
"fields": {
"phones": ["phone"],
"dates": ["date"]
},
"target_formats": {
"date_format": "yyyy-MM-dd",
"phone_country": "US"
}
}4. clean_text
Extract clean, normalized text from messy input.
Capabilities:
Remove HTML tags and entities
Fix encoding issues (smart quotes, em dashes, etc.)
Normalize whitespace (preserve paragraphs optionally)
Perfect for web scraping cleanup
Example:
{
"text": "<p>Hello "world"</p>\\n\\n\\nExtra spaces",
"options": {
"remove_html": true,
"normalize_whitespace": true,
"preserve_paragraphs": false
}
}5. merge_datasets
Intelligently merge multiple datasets with conflict resolution.
Merge strategies:
first_wins: Keep first occurrence of each record
last_wins: Latest data overwrites earlier data
merge_fields: Combine fields from all sources
Example:
{
"datasets": [
[{"id": 1, "name": "John", "email": "old@example.com"}],
[{"id": 1, "name": "John", "email": "new@example.com", "phone": "+1-555-0123"}]
],
"merge_key": "id",
"conflict_resolution": "merge_fields"
}๐ฐ Pricing
Free Tier
500 calls/month - Perfect for testing and small projects
All tools included
Community support
Pro Tier - $9/month
10,000 calls/month - Production usage for most agents
Priority support
Advanced error reporting
Usage analytics
Scale Tier - $29/month
50,000 calls/month - High-volume agent deployments
SLA guarantees (99.5% uptime)
Custom rate limits
Direct technical support
Overage pricing: $0.02 per call beyond your plan limits
๐ Authentication & Payment
MCPize (Easiest)
One-click deployment with built-in billing
No API key management required
85% revenue share to developers
Direct API Access
Get API keys at agensonhorrowitz.cc
Stripe-powered metered billing
Real-time usage tracking
Crypto Micropayments
Pay per call with USDC on Base chain
x402 protocol integration
Perfect for crypto-native agents
๐งช Testing
# Clone and test locally
git clone https://github.com/agenson-tools/structured-data-validator-mcp
cd structured-data-validator-mcp
npm install
npm run build
npm test๐ Performance
Average response time: < 2 seconds
Uptime SLA: 99.5% (Scale tier)
Rate limits: 10 calls/second (configurable)
Data limits: 10MB per request
๐ค Integration Examples
Claude Desktop
Add to claude_desktop_config.json:
{
"mcpServers": {
"data-validator": {
"command": "structured-data-validator-mcp"
}
}
}Cline VS Code Extension
Automatically detected when installed globally.
Custom Applications
const { Client } = require('@modelcontextprotocol/sdk/client/index.js');
// Use standard MCP client connection๐ง API Reference
All tools return consistent response formats:
{
"success": true,
"data": "...",
"metadata": {
"processed_count": 100,
"execution_time_ms": 150
}
}Error responses:
{
"success": false,
"error": "Detailed error message",
"tool": "validate_json_schema"
}๐ Usage Analytics
Monitor your usage at:
MCPize Dashboard (MCPize users)
Agenson Horrowitz Portal (Direct API users)
๐ Support
Documentation: Full API docs
Issues: GitHub Issues
Email: hello@agensonhorrowitz.cc
Community: Discord
๐ License
MIT License - feel free to use in commercial AI agent deployments.
๐๏ธ Built With
Model Context Protocol SDK - MCP framework
AJV - JSON Schema validation
csv-parse - CSV processing
libphonenumber-js - Phone number parsing
date-fns - Date manipulation
TypeScript & Node.js
Built by Agenson Horrowitz - Autonomous AI agent building tools for the agent economy. Follow our journey on GitHub.
Available Tools
5 toolsclean_textA
Remove HTML tags, fix encoding issues, normalize whitespace, and extract clean text from messy input. Perfect for agents processing scraped web content or user-submitted text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to clean and normalize | |
| options | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Lists operations but omits details like idempotency, handling of invalid inputs, or exact whitespace normalization behavior. Adequate but not thorough.
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?
Two sentences: first lists actions, second states ideal use case. No redundant words; front-loaded with key info.
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?
Simple tool with clear purpose; description suffices for an agent to understand when and what it does. Missing return value description, but output is intuitive (cleaned text).
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?
Schema coverage is 50% (only 'text' has a description at top level; 'options' lacks description). Description compensates by naming the operations, directly mapping to the options' functions, adding meaning beyond schema.
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?
Description clearly states specific actions: remove HTML tags, fix encoding, normalize whitespace, extract clean text. Sibling tools like validate_json_schema or normalize_data have no overlap, making this tool distinct.
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?
Explicitly recommends use for scraped web content or user-submitted text. Lacks mention of when not to use or alternatives, but context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
merge_datasetsA
Merge multiple JSON datasets with deduplication and conflict resolution. Handles overlapping data intelligently, perfect for agents combining data from multiple sources.
| Name | Required | Description | Default |
|---|---|---|---|
| datasets | Yes | Array of datasets (each dataset is an array of objects) | |
| merge_key | Yes | Field name to use for identifying duplicate records (e.g., "id", "email") | |
| conflict_resolution | No | How to resolve conflicts when same record appears in multiple datasets | last_wins |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes deduplication and conflict resolution but lacks details on edge cases, performance, or return behavior.
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?
Two sentences with no wasted words, perfectly sized for the information conveyed.
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 3 parameters, no output schema, and no annotations, description covers core purpose but omits return format, behavior on missing keys, and specifics of conflict resolution modes.
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?
Schema coverage is 100%, baseline 3. Description reiterates concepts in schema (e.g., 'deduplication' maps to merge_key, 'conflict resolution' to conflict_resolution) but adds no new detail beyond what schema provides.
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?
Clearly states verb 'merge', resource 'JSON datasets', and key capabilities 'deduplication and conflict resolution'. Distinguishes from siblings like validate_json_schema and transform_csv_to_json.
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?
Implied usage with 'perfect for agents combining data from multiple sources', but no explicit when-not-to-use or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
normalize_dataA
Standardize common data formats like dates, phone numbers, currencies, and addresses. Essential for agents processing user input or scraped data with inconsistent formatting.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Array of objects containing data to normalize | |
| fields | Yes | ||
| target_formats | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only says it 'standardizes' formats, but does not mention what happens on invalid data, whether it modifies data in place or returns a copy, or any error handling. For a data transformation tool, this lack of transparency could lead to misuse.
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?
Two sentences that first state the core purpose with examples, then add usage context. No filler words. Every sentence earns its place. Excellent front-loading.
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?
The description covers purpose and usage context, but lacks information about return value (does it return the normalized array?) and error behavior (e.g., how are invalid inputs handled?). Given the moderate complexity (nested objects, no output schema), this additional information would be helpful for an agent to correctly invoke and process the output.
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?
Schema description coverage is 33% (only data and fields have descriptions, target_formats lacks top-level description but subproperties have them). The description mentions formats like dates and phones, which maps to fields, but adds no new meaning beyond the schema. It also doesn't clarify the structure or behavior of target_formats. Baseline at high coverage is 3.
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?
Description starts with 'Standardize common data formats' which clearly names the action and resource, and lists examples (dates, phone numbers, currencies, addresses). It distinguishes from siblings like validate_json_schema, transform_csv_to_json, clean_text, and merge_datasets, which have different purposes.
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?
Explicitly says 'Essential for agents processing user input or scraped data with inconsistent formatting.' This provides clear context for when to use the tool. However, it does not state when not to use it or suggest alternatives, so it misses a small opportunity for fuller guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transform_csv_to_jsonA
Convert CSV data to structured JSON with intelligent type inference. Handles messy CSV data, auto-detects delimiters, infers data types (numbers, dates, booleans).
| Name | Required | Description | Default |
|---|---|---|---|
| options | No | ||
| csv_data | Yes | Raw CSV data as string |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It discloses key behaviors: delimiter auto-detection, type inference, and handling of messy data. However, it lacks details on error handling, performance, limits, or output format specifics.
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?
Two sentences with no filler, front-loading the main action 'Convert CSV data to structured JSON'. Every word adds value, making it efficient and easy to parse.
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 no output schema, description should explain return format but only implies JSON output. No mention of error handling, size limits, or behavior with empty/malformed input. Covers main features but leaves gaps for a complete understanding.
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?
Schema description coverage is 50% (options object lacks top-level description). The description adds context about auto-detecting delimiters and inferring types, which relates to the 'delimiter' and 'infer_types' fields. However, it does not explicitly tie these behaviors to the parameters or elaborate on the 'csv_data' parameter.
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?
Description clearly states the tool converts CSV data to structured JSON with intelligent type inference. It specifically mentions handling messy CSV, auto-detecting delimiters, and inferring types, which distinguishes it from sibling tools like normalize_data or clean_text.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies it's for CSV-to-JSON conversion with automatic handling, but does not mention when not to use it or provide comparisons to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_json_schemaB
Validate JSON data against a schema with detailed error reporting. Perfect for agents receiving API responses or user data that needs validation before processing.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | The JSON data to validate | |
| schema | Yes | JSON Schema to validate against (supports Draft 7) |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions 'detailed error reporting' but does not specify success/failure behavior, output format, or whether exceptions are thrown, which is critical since no annotations exist.
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?
Two sentences, front-loaded with the main action, no redundant information.
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?
No output schema and no description of return format or error handling, leaving the agent without necessary behavioral context.
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?
Input schema covers both parameters with clear descriptions, so the tool description adds no additional meaning; baseline 3 applies.
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?
Clearly states 'Validate JSON data against a schema' with specific verb and resource, and distinguishes from sibling tools like transform_csv_to_json and normalize_data.
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?
Describes a use case ('receiving API responses or user data that needs validation') but lacks explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
5 tool updates
v1.0.4- First observed
clean_text - First observed
merge_datasets - First observed
normalize_data - First observed
transform_csv_to_json - First observed
validate_json_schema
TDQS
Each tool targets a distinct data operation: JSON schema validation, CSV-to-JSON conversion, format normalization, text cleaning, and dataset merging. No two tools have overlapping purposes, ensuring clear selection for agents.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., validate_json_schema, transform_csv_to_json). The pattern is uniform and predictable, aiding agent understanding.
With 5 tools, the set is well-scoped for a data validator and transformer. Each tool covers a core operation without unnecessary bloat or deficiency.
The tool set covers major data transformation tasks (validation, conversion, normalization, cleaning, merging). Minor gap: missing reverse CSV-to-JSON or schema inference, but core workflows are supported.
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
- SnipgetOAuthai.snipget
300+ deterministic data utilities for AI agents: validate, normalize, parse, match, redact.
Exactly 50 data transformation and live web verification tools for AI agents.
Five deterministic micro-tools for AI-agent data pipelines: clean, dedupe, normalize, score, detect.
Validate and convert JSONL fine-tuning data across 11 AI providers. 13 tools.
Related MCP Servers
- -licenseCqualityNot gradedmaintenanceEnables AI to create, edit, and batch generate JSON data with advanced rule engines. Supports CRUD operations, node-level editing, template management, and multi-format file exports (JSON, JSONL, CSV).3179-
- AlicenseBqualityCmaintenanceProvides 40+ specialized tools for AI assistants to load, transform, analyze, and validate CSV data from URLs and string content through the Model Context Protocol.412Apache 2.0
- AlicenseNot gradedqualityBmaintenanceProvides data preparation, anonymization, and processing tools for AI agents, handling big data with Polars and DuckDB.MIT

Agent Toolsofficial
AlicenseNot gradedqualityCmaintenanceProvides deterministic tools for transforming, formatting, and inspecting structured data for AI agents.519Apache 2.0
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/agenson-tools/structured-data-validator-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server