microsoft BCTech: the Business Central technology samples Microsoft shares

Why a vendor publishes its prototypes

The BCTech repository is described as the Business Central technology samples, and the README explains the reasoning in the first person, which is the most interesting part of it.

In the Business Central development team, they say, they are passionate about technology, and the repository is for a Business Central developer or a technology enthusiast who shares that passion. Then comes the explanation. In the research and development team they work hard for each release to implement new features, but a developer knows that a lot of other things happen in the process. They do prototypes, they investigate new technologies, they set some intricate experiments to test performance, they try out new processes.

Most of this work never makes it out of the four walls of Microsoft, and the team realised that some of it might be of value to the members of the tech community, so instead of keeping it to themselves they decided to share.

That framing sets the expectation correctly. This is a repository of experiments, and a sample that is here is a sample that was interesting enough to publish, not a pattern that Microsoft supports or maintains. The closing of the README asks for feedback, comments, and opinions, and also asks to be told what people want to hear about.

The project has adopted the Microsoft Open Source Code of Conduct, and the README points at the code of conduct FAQ and gives an address for questions or comments. The licence is MIT, the primary language is AL, which is the Application Language that Business Central extensions are written in, and the repository is not archived, with the last push on 2026-10-13.

There is only one release in the history, a 1.2 tagged for the Dynamics 365 Business Central troubleshooting guides in December 2021, which tells you how the repository is versioned, if at all.

The samples directory, sorted by theme

The repository does not document each sample, which is worth saying plainly, because it means the directory names are the map you navigate by. The top level has a samples directory, a workshops directory, and a directory for non production applications.

The samples directory is dominated by Azure integration work. There is a sample for Azure IoT Central, one for Azure Service Bus, one for Azure Storage, one for Azure Data Lake integration, one for Azure OpenAI, and one for AppInsights. There is a .NET add-in sample, an admin center API sample, and an API query generator sample.

Then there is the artificial intelligence cluster, which is the one that has grown the most in the shape of the names. There is an AI data generation sample, an AI failure analysis sample, and a BC agents sample.

And there is a set of samples that are about the platform itself rather than about an integration. There is a Business Central services access sample, a compression sample, a cloud migration sample, a sample for cloud access to local resources, a clearance service sample, a C# OAuth sample for accessing Business Central, a Contoso demo data sample, a data analysis sample, and a CTF challenges sample, which is a nice touch for a repository that wants people to try things rather than read about them.

Two of these names point at an area that has become its own subject in the last couple of years. The business central platform team is shipping a set of MCP proxies, with one for the admin center, one for the platform itself, and one written in Python, and the samples are named after that pattern.

The MCP proxies, and why there are three of them

Three directory names deserve their own paragraph, because they point at a specific architectural question: how does an AI agent get at Business Central data, and where does that boundary belong.

There is a proxy for the admin center, one for Business Central, and one written in Python. Read together, they describe three different placements of the same idea. The admin center proxy is the narrowest, exposing the administration surface. The platform proxy is the general one, exposing the business data. The Python one is a different implementation choice rather than a different target, and its presence next to the others tells you the team was working on the shape of the protocol and not just on one adapter.

That is the significant part of this collection, and it is the part a reader outside the Business Central world will find most interesting. An MCP server is the mechanism that lets a language model act on a business system, and the security question that raises is where the credential boundary goes. A proxy that sits between the model and the platform is a place to put authorisation, and the fact that a vendor is publishing three of them, one of them in a language other than the platform's own, suggests the team was treating that boundary as a design problem rather than an implementation detail.

None of the directories carry a readme in the listing, so a reader is left with the names and the code. That is the nature of this repository, and it is also the instruction: the samples are meant to be opened and read, and the names tell you which ones to open.

Workshops, non production apps, and the security file

The two other top level directories serve different purposes from the samples.

The workshops directory is the teaching material, and its presence alongside the samples tells you the repository is meant to be used in a training context, where a workshop needs something to demonstrate. A workshop sample tends to be scoped, self contained, and designed to be explained in a room, which is a different discipline from a sample that demonstrates an integration end to end.

The directory for non production applications is the one to be careful with, and the name is doing the warning. These are applications that are not intended to run in production, and in a repository published by a vendor, that is a strong signal. A non production application might have hardcoded configuration, might skip the authorisation checks, might assume a test tenant, and might not survive a data model change. It is a starting point for a conversation, not a component to deploy.

The repository also carries a LICENSE file and a SECURITY.md, alongside a code of conduct notice in the README and a contributing guide. The security file is the one to read first if you find a problem in a sample, and it is the correct place to report it, rather than a public issue.

Taken together with the README's own framing, the picture is of a curated dumping ground of in house experiments, published because the team thought some of it had value for the community. The directories are organised by technology area rather than by scenario, which makes the repository browseable but means you have to know what you are looking for, or read the names and pick.

What this collection is, and what it is not

It is worth being clear about the category, because Business Central samples usually mean something narrower.

A vendor sample repository for a business application platform is usually a set of small extensions that show a feature working, usually in the vendor's own scripting language, usually with a readme explaining the setup step by step. BCTech is not that, and the README says so.

What it is, is the experimental layer. The prototypes, the investigations of new technologies, the performance experiments, the process experiments, and the research work that does not make it into a product release. Some of it is an Azure integration, some of it is an AI sample, some of it is an interface to the platform that exists because a team was exploring an interface, and some of it is a capture the flag.

The practical value is different too. A documented sample tells you how to do something. A prototype tells you that something is possible, and it hands you the code that proved it, with the understanding that the code was written by people who work on the product rather than by people who document the product. That is a different kind of useful, and for the specific question of what is being tried in the platform team right now, it is a better one.

Two cautions follow from that. The samples are not versioned in step with the product, so a sample written against one release can need work on the next, and a Business Central extension is coupled tightly to the version it was built for. And the non production applications are not production applications, whatever their code looks like.

The repository asks for feedback and for requests, which is the right way to treat it. If you want to hear about a particular area, the team has asked to be told, and that is the route to a sample that does not exist yet.

Editorial conclusion

BCTech fits a Business Central developer who wants to see how Microsoft itself wires the platform to Azure services or to a language model, or who wants a working MCP proxy between Business Central and an AI agent, and who is comfortable reading a sample rather than a tutorial. It does not fit someone who wants supported, documented guidance, because the README states that most of this work never made it out of Microsoft and is shared as a good-faith sample, and it does not fit a production project, since the applications directory is explicitly for non production apps. Verify first that the sample you want still matches the current Business Central version, since the repository is not versioned in lockstep with the product, and that you read the code of conduct and the security file before contributing.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/BCTech on GitHub
4. README
5. Releases