Custom MCP Development

An API exposes an application’s functions to other software. The Model Context Protocol is an open standard that standardises how AI applications discover and use selected context and tools, which is a different problem: a model needs to know what is available, what each tool does, what it expects and what it returns. A custom MCP server usually calls the application’s API underneath rather than replacing it. Nothing about your existing interfaces, identity systems or application rules stops being relevant.

Usually, yes, and a documented service interface is by far the strongest foundation. Where one does not exist we will assess the alternatives case by case, but we are cautious about driving an application through its user interface: it is fragile, it breaks on cosmetic changes, and it is difficult to secure or audit. Sometimes the right recommendation is to build a proper interface first, which is a smaller job than it sounds and a considerably better position to be in.

Yes, and it often should be to start with. Read-only, write-enabled and approval-gated designs are all available, and the right choice depends on the business need and on how reversible the action is. A common pattern is to begin read-only, prove the model uses the tools sensibly, then add write capability behind an approval gate once there is evidence rather than optimism to support it.

That depends on each host’s support for the protocol and on how it is implemented there, so we will not promise universal compatibility. What we do instead is agree the target environment with you at the start and test against it. A connector built to the specification has a reasonable chance of working with other compatible hosts, but reasonable chance is not the same as tested, and we would rather be precise about which one you are getting.

Either, and the choice shapes everything else. A local server runs on the user’s own machine, uses that user’s credentials and is only reachable from the AI application running alongside it. A hosted server runs as a service, serves many users, has to establish who each of them is, and needs the same operational care as any other production endpoint. Which AI applications can use the server, how authentication works, where secrets live and who operates it all follow from this decision, so we take it during assessment rather than leaving it to deployment. Most business use cases end up hosted; most first experiments end up local.

Authentication and strong secret management, least-privilege scopes with read and write separated, a clear decision on whether the server acts as the individual user or as a service account, since that determines what an audit log can actually prove, explicit consent for sensitive actions, validation of what the model passes to a tool rather than trusting the parameters it generates, environment isolation, rate limits and timeouts, audit logs linking user, model, call, result and approval, and protection against prompt-injection paths that attempt to misuse a tool or reach unauthorised data. We also review the underlying API, because a connector cannot be more secure than what it calls. Little of that comes from the protocol itself. It standardises how an AI application discovers and calls tools, specifies how a client authorises against a remote server, and lets a tool declare hints such as read-only. What a tool is allowed to do, on whose behalf, and what gets recorded are engineering decisions.

It will, so we plan for it. Versioning of the connector, regression tests against the tools you depend on, monitoring that detects a change in behaviour rather than waiting for a user to report it, and documentation that makes the dependency visible. Whether Koios or your own team handles that maintenance is worth agreeing explicitly at the outset rather than discovering after the first breaking change.

Then you compare them on coverage, security and maintenance, and pick. That is a good position to be in rather than a wasted investment: you will have been running the use case for a year while waiting. Sometimes the vendor version is better and the custom one gets retired. Sometimes it covers the general case and yours keeps the domain-specific tools that match your own processes. We would rather build something you can retire cleanly than something you are locked into.