Grounding AI Coding Agents in Xperience by Kentico's Real API

AI coding agents have become a normal part of building Xperience by Kentico projects. Point one at a ticket that says "add a widget that lists related articles" and it will happily wire up a view component, reach for IContentRetriever, and write a Razor view. Most of the time it works. Every so often, though, the agent encounters an unfamiliar API and starts decompiling the platform's assemblies just to find a type or method signature.

For a developer, that kind of lookup is usually handled by IntelliSense. An agent needs an equally direct way to discover available types, parameters, and overloads. Kentico's official API reference provides it.

Why XbyK Is a Hard Target for a Coding Agent

Xperience by Kentico is closed source. Unlike an open-source library where an agent can simply read the implementation, XbyK ships as compiled NuGet packages, and the true contract of a type — its constructors, overloads, nullability, and which members are actually meant for consumers versus internal plumbing — only exists in the metadata and in whatever documentation Kentico publishes alongside it. That is not unusual for commercial platforms, but it changes the odds for an agent that is used to leaning on source code as its primary source of truth.

Xperience by Kentico also covers a broad range of features, with content types, web page items, reusable schemas, Page Builder widgets, and management and content-query APIs spread across different namespaces. As the platform evolves, a model's training data can become outdated in the places that matter most for working code: available interfaces, method names, and overloads.

The Documentation MCP Helps, But It Answers a Different Question

Kentico already ships a Documentation MCP server as part of the broader KentiCopilot effort, exposing tools that search and fetch current documentation as Markdown. It is usually the right first move for an agent that needs to understand a concept: how content item permissions work, what a reusable field schema is for, or what the recommended pattern is for building a Page Builder section.

The gap shows up once the agent moves from "what is the right approach" to "what exactly do I call." Conceptual documentation describes patterns and best practices in prose, with a handful of illustrative code samples, but it was never meant to enumerate every constructor overload, every optional parameter, or the exact return type of a specific method. An agent trying to call IContentQueryResultMapper.Map correctly needs the actual signature, not a paragraph about content query results in general. That is precisely the kind of question conceptual documentation, however well written, is not built to answer.

When a Lookup Becomes Unnecessary Decompilation

Faced with that gap, an agent may locate the relevant DLL in the NuGet package cache and inspect its decompiled code. Decompilation can be useful when investigating implementation behavior or diagnosing a problem in the exact package version a project uses.

For a simple type or method lookup, however, implementation details are usually unnecessary. The agent needs the same information a developer gets from IntelliSense: the declaration, available overloads, parameter types, and return value. The API reference presents that information directly, together with descriptions and usage remarks.

A Better Ground Truth: api-reference.kentico.com

Kentico publishes api-reference.kentico.com, a generated API reference organized by namespace and type. Namespace pages list the types they contain. Type pages show declarations, inheritance, implemented interfaces, and applicable constructors, methods, and properties, with parameter names and types spelled out explicitly.

Predictable URLs let an agent fetch a namespace listing or go straight to a specific type:

https://api-reference.kentico.com/api/{Namespace}.html
https://api-reference.kentico.com/api/{Namespace}.{TypeName}.html

The reference also provides remarks that help identify intended usage and restrictions. A public declaration alone does not mean an API is supported for custom code: for example, the documented DefaultDataSettings class is explicitly marked for internal use only. Reading those remarks is part of the lookup.

There is one important limitation: the API reference does not display version information. An agent cannot establish from a page alone whether its signatures match the NuGet packages installed in a particular project. The reference is a direct source for API discovery, but the resulting code still needs to be checked against the project's installed packages and verified with a build.

The next step was making this lookup process available to agents as a reusable skill.

Turning the Observation into an Agent Skill

Agent Skills package task-specific instructions in a SKILL.md file, with optional scripts and supporting resources. Several agentic tools, including GitHub Copilot, Claude Code, and Codex, support them. This skill supplies instructions for using capabilities the agent already has, such as fetching a web page.

The xbyk-api-lookup skill is designed for tasks that require an XbyK type, method signature, interface, or namespace. It directs the agent straight to the official API reference. Conceptual guides and configuration walkthroughs remain outside its scope.

The instructions use the two URL patterns above to discover types in a namespace or inspect a particular type. They specify what to extract: the declaration and namespace, base class and implemented interfaces, public constructors, method signatures and return types, properties, and relevant remarks or exceptions.

The skill also covers looking up service interfaces and finding extension methods through namespace listings. Its checklist prompts the agent to verify type existence, parameter names and types, nullable annotations, and required parameters before writing code.

Where the environment supports background agents, the skill asks one to fetch the page and return the specified API details to the main agent. This keeps the main conversation focused on the lookup result.

Packaging and Sharing the Skill

To make the skill easy to share across projects, it is packaged as the xperience-by-kentico plugin in the public Bluesoft Agent Skills marketplace on GitHub.

The marketplace provides installation instructions for GitHub Copilot CLI, VS Code, Claude Code, and Codex. Setup differs by tool, so follow the instructions for your agent. Once installed and enabled, the skill is available for relevant API lookup tasks.

The skill complements the existing KentiCopilot tooling. The Documentation MCP server supports conceptual questions, while the Content Modeling and Management MCP servers support designing content models and working with a project's objects. The API lookup skill provides a focused path to the documented shape of a type or method.

What Changes in Practice

With the skill installed, the same "add a widget that lists related articles" request plays out differently. The agent fetches the relevant type page, checks the method signatures and usage remarks, and writes code against the documented API.

Suppose the widget needs article pages from a particular section of the website. Knowing that IContentRetriever retrieves content is only the starting point: the agent also needs the right extension method and the parameter class accepted by its overload. The RetrievePagesExtensions reference shows that RetrievePages<Article> accepts a RetrievePagesParameters object. Following that type's reference page reveals its available options, including ChannelName, PathMatch, and LinkedItemsMaxLevel.

The lookup connects the extension method to its specific parameter class, then to the types and members needed to configure it. It prevents the agent from passing a similarly named RetrieveContentParameters object or assigning a string to PathMatch. Those details are available directly in the reference, without reconstructing them from decompiled implementation code.

The difference shows up as fewer compile errors on the first attempt and less risk of the agent calling an unsupported member. Checking the reference's remarks and building against the project's installed packages remain part of validating the result.

Takeaway

The improvement comes from giving the agent a clear lookup workflow: find the type, read its signatures and remarks, and validate the code in the project. For the everyday questions developers answer through IntelliSense, Kentico's API reference gives agents a straightforward place to look. The skill makes that resource a consistent part of their workflow.