Semantic Kernel or Agent Framework using OpeanAPI with JsonPolymorphic

Question

I am working on a concept that uses a JSON OpenAPI definition for a local service intended to be consumed by an AI via Semantic Kernel. The service relies on a type descriptor mechanism to reduce the number of controller functions.

However, the core issue is that, regardless of what I include in the OpenAPI description, the AI calls (using the GPT-4.1 model) consistently fail to construct a valid JSON payload—even for a very simple DTO that contains a type-descriptor field and a string property representing a material name.

During my investigation, I observed that Semantic Kernel effectively transforms the OpenAPI.json into a set of generated functions exposed to the AI. Unfortunately, the results of this transformation are highly disappointing and appear to significantly limit the AI’s ability to correctly infer and construct the required JSON structures.

My intuition is that the OpenAPI JSON specification should be provided directly to the AI, without being parsed or abstracted into function definitions. That said, this is currently just an assumption, and I may be mistaken.

Given this situation, I am uncertain whether it is worth continuing to invest in this approach or whether I should pivot to an alternative architecture—possibly leveraging the Agent Framework instead.

Answer 1

Semantic Kernel does not expose the raw OpenAPI schema to the model. It converts it into function definitions, and during that transformation a lot of structural context (DTO shape, discriminators, type descriptors) is lost. Because of this, the model often fails to construct valid JSON payloads even for simple DTOs.

So the issue is not your OpenAPI spec — it’s the lossy abstraction layer SK introduces.

Your intuition is correct @Florin Bugan : LLMs perform better when they can reason over the actual schema, not a flattened function signature. If your API relies on polymorphism or type-descriptor patterns, SK’s OpenAPI integration will be fragile.

For now, either:

simplify the API contract to be LLM-friendly, or

move to an agent-style approach where the schema is provided as context and outputs are validated before execution.