MCP servers
MCP, the Model Context Protocol, is the open standard an AI assistant uses to reach into your systems: a database, a CRM, files, an internal API. Instead of pasting data into a chat window you give the assistant narrow, named tools: "check this order", "draft this document from the template", "find this contract". I write that server, agree the allow-list of operations with you, and keep reads separated from writes so every call leaves a trace.
Let's talk about your projectWho is it for?
For companies already using an AI assistant and hitting the same wall: it does not know your data, and pasting it in by hand is slow and risky. It pays off when the data sits behind an API or in a database, and when you can name the questions the assistant should answer.
What can we build?
- The tool list: each tool named, described for the model, with its inputs and exactly what it is allowed to do.
- An MCP server in TypeScript wired to your sources: database, CRM, invoicing, files or your own API.
- Reads separated from writes: anything that changes data is switched on deliberately and confirmed by a person.
- Authentication and scopes, a call log for audit, and limits so one question cannot pull the whole database.
- Instructions for connecting it in the client you use, and how to add a tool later.
Tools chosen for the job.
We pick the stack to match your processes, your budget and the systems you already use.
How do we work?
- We write down the questions the assistant should answer and the actions it should take.
- I check where that data actually lives: API, database, files, and what the limits and permissions are.
- I build the server with a narrow tool list, read-only first, and we test it on real questions.
- We add write operations where they earn their place, with human confirmation and an audit log.
- We connect it in your environment and agree who adds the next tool.
Worth knowing.
How is an MCP server different from a normal API integration?
An API integration wires two systems together along a fixed path somebody programmed. An MCP server hands the assistant a set of tools and the model decides which one answers the question in front of it. That is why the allow-list and the tool descriptions matter more here than the transport.
Does my data go to the model provider?
Only what a called tool returns reaches the model, so the scope is set by the design of the server, not by a chat setting. We agree which fields leave the system at all, and they can be narrowed or masked. The provider terms are a separate decision we read before rollout.
Can the assistant break something?
Only what you allow. The default build is read-only; anything that changes data is added separately, confirmed by a person and written to a log. If a tool is not on the list, there is no path to the action.
Which assistants does it work with?
MCP is an open standard, so the same server serves any client that supports the protocol. Changing assistant does not mean rewriting the integration.
Where should we start?
With one process and the three questions asked most often. A server with a few read-only tools is quick to build and shows straight away whether the assistant actually saves time. Growing it makes sense only after that test.
Your idea.
Our first step.
Describe what you want to achieve. We'll agree on the scope, the stages and a quote.
Jonasz Jankowski · Direct collaboration · Mikołów (Silesia), remote across Poland