Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If the function stays the same, why rewrite its tool wrapper for every LLM framework? A single tool might be exposed through an AI SDK application and an MCP server, yet each integration can expect different fields, schema formats, and result handling. A framework-independent tool definition could reduce that duplication—but only if adapters and other projects adopt it.
Why framework tool objects are similar but not interchangeable
Frameworks describe familiar concepts: a tool has a name, a description, an input shape, and a function to run. But those concepts do not necessarily occupy the same fields or use the same schema types. For instance, AI SDK uses a key in a tool map, Mastra uses an id, Genkit uses name, and LangChain puts its input schema in schema. MCP tools are registered through a different API. As Andrey Gubanov puts it, “The objects look alike, but they are not interchangeable, and each one needs its framework’s package.”
This difference matters when a library wants to offer one reusable tool to applications using different frameworks—or to expose it both to a framework and a protocol server. Without a shared definition, developers either maintain multiple wrappers or make their library depend on a particular framework’s package.
Why schema portability is the hard part
Validation interfaces and JSON Schema solve different problems
Standard Schema provides a common TypeScript interface through which consumers can work with validation libraries. Standard JSON Schema addresses conversion: it can export a schema in a JSON Schema dialect a consumer supports. They are related specifications, but they are independent; a shared validation interface alone does not guarantee every provider will accept the same JSON Schema dialect.
Input and output schemas may also differ. A validator can accept one representation and transform it into another—for example, accepting a string and producing a number. An adapter therefore needs to know which schema describes arguments supplied to the tool and which describes the value returned from it.
A declared schema is not runtime validation
A schema can tell a model or integration what arguments are expected, but merely declaring it does not guarantee that incoming arguments have been validated before execution. The tool implementation must validate them itself, or use a wrapper that does so. The same consideration applies to results when output validation is required.
What the proposed StandardToolV0 contains
StandardToolV0 is a proposed framework-independent TypeScript shape, not an adopted industry standard. It groups a tool’s description and schemas with the function that executes it:
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →name, plus an optional human-facingtitleand adescription.- Optional
inputSchemaandoutputSchema. - Optional static
meta. execute(input, context?), where the optional context is not validated or represented in JSON Schema.
The interface itself is types-only. The proposal also describes an optional standardTool() reference wrapper that checks arguments and results against schemas, and a withFormattedOutput() helper that returns errors as data. These helpers are distinct from the basic shape: developers should not assume that a type declaration alone checks runtime values.
How framework and provider adapters fit in
A shared definition does not eliminate integration-specific work. An adapter translates the tool into the declaration a framework or provider accepts, invokes its execution function, and formats the result for that consumer. The source article describes these mappings as follows:
| Consumer | Schema or declaration described | Result handling described |
|---|---|---|
| OpenAI Responses API | JSON Schema draft 2020-12 | function_call_output |
| Anthropic | JSON Schema draft 2020-12 | tool_result |
| Gemini | OpenAPI 3.0 | functionResponse |
| MCP | inputSchema in the tool descriptor |
MCP content fields |
| AI SDK | Accepts Standard Schema directly | SDK-managed execution |
These are mappings reported by Gubanov’s article, not a guarantee that every integration has identical behavior across versions. In particular, the adapter or execution code still needs to handle validation if unchecked model arguments would be unsafe.
What the framework comparison does—and does not—establish
Gubanov’s comparison says the frameworks differ in where tool identifiers live, which schema field they use, and where execution functions are supplied. It also reports differences in accepted schema forms. The comparison was checked against ai 7.0, @mastra/core 1.72, genkit 1.42, @langchain/core 1.2, and @modelcontextprotocol/sdk 1.31 for the article published September 30, 2026. Treat that as a dated version snapshot, not as a statement of current package versions or a universal description of later releases.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchThe practical comparison is not simply which object looks most familiar. Evaluate whether each consumer accepts the schema library and JSON Schema dialect you need, whether values are validated at runtime, how much adapter code is required for declarations and results, and whether reuse would otherwise force a framework dependency.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Is a shared tool object worth adopting?
It is a useful direction when a team owns tools that must work across multiple frameworks or protocols: one canonical definition can keep metadata, schemas, and execution together while adapters handle consumer-specific formats. But StandardToolV0 remains a proposal, and the article identifies one maintainer. Without projects that produce or consume the shape, it could become another isolated format rather than a common interface.
Before adopting it, check the proposal’s current implementation and compatibility for the packages you actually use, and decide who will maintain the adapters and validation behavior. The source article presents the shape and helpers as a proposal; it does not establish broad ecosystem adoption.
Read Andrey Gubanov’s original article on DEV Community.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
