Let AI assistants use your product with a person’s permissions.

Because an assistant can’t use an API the way a developer does. A developer reads the documentation once and writes code against it. An assistant has to work out, partway through a conversation, which action fits what someone just asked. An MCP server hands it a short described list in place of your whole API. It sits on top of the API and replaces none of it. Until a customer asks for this, you can leave it.

It should work with any assistant that supports the protocol, and we test it with the ones named in your scope. The protocol’s documentation, as we read it on 15 November 2026, listed Claude and ChatGPT as assistants that support it, and Visual Studio Code and Cursor among the development tools. We test each one separately: the same questions go to each, and we reword an action where one of them picks wrongly.

It can be, and that depends on the permissions more than on the protocol. We build each action to run as the user who asked, so it can do only what that user could do in the product. Every call is logged and access can be switched off. The specification, as its documentation stood on 15 November 2026, leaves authorisation optional, so the care has to come from the build. Testing lowers the chance of an assistant misreading a request and cannot remove it.

It depends on the scope, and the price is settled before the project starts. The usual first step is one week of work for $2,500, in which we decide with you which actions an assistant should have and what each may touch. If the build begins within 60 days, the whole $2,500 is taken off its price.

We agree the timeline before work starts. It depends on three things: how many actions the server offers, how sign-in and permissions work in your product, and which assistants it has to be tested with. A first week of work settles the list of actions, so the timeline that follows rests on a decided scope.

A working MCP server in your own accounts, with its code and documentation. That includes the actions and the wording of each, permissions tied to the user who asked, a log of every call and a way to switch access off. The test questions come too, so your engineers can run them again after a change.

Three things: your API and its documentation, a test environment with sample accounts, and time with whoever knows how sign-in and permissions work. We work in your repository and through your code review, so your engineers have read the server before it goes live.

Whoever you choose, and we agree it before launch. We can keep looking after the server, or your engineers can with the documentation we leave. It needs an owner either way, because the protocol is still being revised: on 15 November 2026 its documentation gave 28 July 2026 as the date of the current revision. Your product changes too, and an action describing an old feature can mislead an assistant.

Yes. Our studio is in Sydney, Australia, and MCP server development is part of our engineering service. We build the server so an assistant can read and act on your product with the permissions a person would have. The people who design here also build, which helps when much of the work is naming and describing actions. We usually work with companies that have raised a seed or Series A round.