Introducing Standard Schema 1.0 — Removing Zod Dependencies from AI Agent Tools

Why have we always been forced to use Zod when providing new tools to AI agents? Until now, countless agent frameworks have been too tightly coupled with Zod for defining and validating tool input data structures.

However, the landscape of the agent ecosystem is changing rapidly. The Model Context Protocol (MCP) TS SDK v2.0 and agent frameworks like Mastra v1.2.0 have now fully adopted 'Standard Schema v1.0'.

Developers can now freely mix and match lightweight, high-performance validation libraries like Valibot or ArkType according to their preferences, rather than relying solely on Zod. Let’s explore this new trend that is set to make agent development environments more flexible and lightweight.

Why Only Zod? The Beginning of Dependency Hell

For LLMs to use external tools, they need to clearly understand the specification of the input data. This is because a 'JSON Schema' that tells the AI, "To run this tool, send the values in this format," is essential.

For some time, developers in the TypeScript environment have conventionally used the Zod library to define these complex schemas and validate inputs. Because it elegantly handles both TypeScript type declarations and real-time data validation, it became the de facto standard for building agent tools.

However, this coupling led to an unexpected 'dependency hell.' It was common for agent frameworks or SDKs to internally force a specific Zod version, which often conflicted with the latest versions used in the developer's project. Furthermore, it created inefficiencies, forcing developers to include the heavy and bulky Zod package even when they wanted to use more lightweight validation tools suited for slim and fast edge environments.

Standard Schema v1.0 — Unifying All Validation Libraries

Simply put, Standard Schema v1.0 is a common agreement that helps people speaking different languages communicate without obstacles. It is not a new data validation library itself. Instead, it is a very lightweight and simple interface system that allows tools with different validation approaches—like Zod, Valibot, and ArkType—to communicate using a single common set of rules.

The core principle is very simple. All libraries that follow the standard just need to provide an agreed-upon space named ~standard inside the object and provide a common validation method named validate.

// Standard Schema v1.0 규격을 따르는 스키마 객체의 기본 구조
const mySchema = {
  "~standard": {
    version: 1,
    vendor: "valibot",
    validate: async (value) => {
      // 검증 라이브러리가 내부적으로 처리 후 표준화된 결과 반환
    }
  }
};

Having such a defined specification makes things very convenient for developers creating agent frameworks or SDKs. Regardless of whether a user chooses Zod or Valibot, they can always securely validate data using the same ~standard.validate() approach.

The extended specification tailored for AI agent environments is particularly useful. For an LLM to use a tool correctly, it must be able to read the JSON schema containing the input data specification. By utilizing this standard, you can immediately and securely extract the JSON schema understood by the LLM from the schema without needing separate converters.

How MCP SDK v2.0 and Mastra Utilize This Standard

The fact that this standard is rapidly becoming the mainstream in the actual agent ecosystem, rather than just a mere technical proposal, is made clear by looking at key recently released tools.

The most significant change occurred with the MCP TS SDK v2.0 released in late July 2026. Prior versions required an absolute dependency on Zod schemas when defining tool input formats. However, from v2.0, the Zod dependency has been completely removed in favor of the StandardSchemaWithJSON interface based on Standard Schema. Developers can now build tools by freely selecting the optimal validation tool for their project, such as Zod v4, Valibot, or ArkType, without being locked into a specific library.

Another powerful agent framework, Mastra v1.2.0, has also acted swiftly. To cleanly resolve conflict issues between different validation tools, Mastra introduced a compatibility package called @mastra/schema-compat. By using the toStandardSchema() function provided by this package, you can seamlessly convert Zod v3, v4, or various AI SDK schemas into a single unified standard format.

You can understand at a glance how this technology is used in real code by looking at Mastra’s integration method.

// Mastra v1.2.0 기반 스키마 변환 예시
import { toStandardSchema } from '@mastra/schema-compat';
import { z } from 'zod';

// 평소처럼 작성한 Zod 스키마
const userProfileSchema = z.object({
  name: z.string(),
  age: z.number().int().positive(),
});

// 스탠다드 스키마 표준 포맷으로 간편하게 변환
const standardSchema = toStandardSchema(userProfileSchema);

Schemas converted in this way work consistently throughout the entire process, from the agent passing the tool specification to the LLM to re-validating the input values. With the restrictions of being tightly bound to specific libraries removed, a flexible environment has opened where developers can freely pick and choose the puzzle pieces they want.

The Unexpected Pitfall in Cloudflare Workers

When deploying agents to lightweight edge environments like Cloudflare Workers, you must be wary of unexpected obstacles. This is a common issue when using converters that transform various validation tools into standard specs, such as @mastra/schema-compat from Mastra v1.2.0.

The most notable pitfall involves the refine or superRefine methods used for detailed validation in Zod schemas. Applying these methods changes the Zod schema type from ZodObject to ZodEffects. To handle this specific type, the converter internally attempts to dynamically compile a JSON schema in real-time by utilizing libraries like AJV.

At this point, it calls JavaScript's dynamic code execution function, new Function(), but Cloudflare Workers, based on security-strict V8 isolates, strictly block this command. As a result, the agent crashes and throws an error the moment it attempts to invoke the tool.

// ❌ 엣지 환경에서 에러를 일으키는 패턴
const bugSchema = z.object({
  apiKey: z.string(),
}).refine((data) => data.apiKey.startsWith("sk-"));

// ✅ 안전한 패턴: 스키마는 단순하게 유지하고, 검증은 실행 함수 안에서 처리
const safeSchema = z.object({
  apiKey: z.string(),
});

Therefore, when defining tool schemas in edge environments, it is much safer to define only simple, basic types whenever possible and handle complex custom validation logic within the actual execution function of the tool, outside of the schema.

A Lighter and More Flexible Agent Ecosystem

The introduction of Standard Schema v1.0 signifies a change that goes beyond just swapping a data validation library. Thanks to the flexibility of not being tied to a specific validation tool, the portability of the agent tools we develop in the future will be significantly enhanced.

Developers are now free from framework constraints and can pick and choose only the features they need to build light and fast agents. We look forward to a more modular and lightweight agent development environment driven by MCP TS SDK v2.0 and Mastra v1.2.0.