The agent has a bounded job.
Required tools, allowed actions and limits can be tied to a concrete business process.
All services
MCP servers
Your agent is meant to reach real systems. The question is whose rights it uses.
An MCP server is quick to build. The reference implementation is a few dozen lines, and in a demo everything runs through one technical account that is allowed to do anything. As soon as real users depend on it, that is exactly what becomes the problem: everyone gets whatever the account is allowed to do, and the log only says that "the agent" did it. I build MCP servers so that the identity of the user is carried through to the tool call.
AWS Certified Generative AI Developer – ProfessionalOAuth 2 & token brokerAudit trailFrom 3,900 €
What you get
- An MCP server in your environment, not on a laptop
- User identity carried through to the tool call, no shared account
- Tools with limits: whatever writes needs a confirmation
- An audit trail that answers the question "who triggered this"
- A cost cap and quotas per user and per use case
- Infrastructure as code, so the second server is not hand work
Scope & working together
One use case with one connected system, at a starting price. Further tools and systems afterwards by scope, never as an open bill.
Remote from Germany. Straight with me, no agency in between.
The starting point
The server is not the hard part.
The Model Context Protocol is deliberately kept simple. A server offering a handful of tools is written in an afternoon, which is exactly why there is one for almost every system by now. In a demo that works fine: one technical account, one key in an environment variable, done. The demonstration convinces, and afterwards somebody asks whether this could not go into production.
From there on the questions are different ones. When the agent cancels an order for Ms Meier, does it do that with her rights or with those of the shared account? When somebody asks two weeks later who changed the record, does the log show a user name or "mcp-service"? And when a tool is called twice by accident, does one booking appear or two? These are not edge cases, they are normal operation.
On top of that comes the cost side, which is particularly unpleasant with MCP: every tool call returns text that lands in the context and gets paid for again at the next step. A tool that answers generously drives the bill up with every further step. Prompt caching dampens that, because the prefix sent again and again drops to roughly a tenth of the input price, but it does not remove the effect: you still pay per step. Whoever has not set a cap beforehand notices it on the monthly invoice.
Does any of this sound familiar?- The agent works with a technical account that is allowed to do more than any single user.
- The log says that something was changed, but not on whose behalf.
- A tool call writes into a production system, and there is no way back.
- Nobody can say what one user costs per month in tokens.
- Text from a ticket gets the agent to call a tool nobody had planned for.
- The server runs on the machine of the colleague who built it.
Who this is for
For teams whose AI agent must access real systems with the right user’s permissions.
For CTOs, platform and AI teams with existing backends and authorization models. The agent must do more than answer text: it needs to read or act under control.
Identity and permissions matter.
Users may see different data or trigger different actions, making a shared service account unacceptable.
Every access must be traceable.
Audit trails, limits, failure behaviour and cost control are product requirements from day one.
What I do
What gets built along the way
01
The scoping before the build
Which systems should be reachable, which actions an agent may trigger, and where it stops. Whatever has an interface can be connected: databases such as PostgreSQL, MySQL or MongoDB, ERP and inventory systems such as SAP, Microsoft Dynamics 365 or DATEV, a CRM such as Salesforce or HubSpot, ticketing systems such as Jira, and applications of your own with a REST or GraphQL API. The result is a list of tools with limits, not an interface with everything the system happens to offer.
02
Identity instead of a shared account
The signed-in user is carried through to the tool call via OAuth 2, with a token broker in between. The agent never gets more rights than the person it acts on behalf of.
03
Tools that are allowed to write
Reading tools are easy. Writing ones need three things: a confirmation by a human, idempotency against the duplicate call and a bounded effect. Without that, a tool in a production system is a risk without a return.
04
Audit trail
Who called which tool when with which arguments, and what came back. Complete, stored immutably and open to analysis, because exactly that question comes up later, usually on an inconvenient day. How long it is retained and where is settled in the scoping.
05
Costs with a cap
Quotas per user and per use case, response sizes of the tools bounded, cost per operation visible. Otherwise a tool that answers generously becomes the most expensive part of the system without anyone noticing.
06
Operations and repeatability
The server runs in your environment, described as infrastructure in code, with metrics and tracing. The second server is then a configuration and not a new project.
Should your agent reach a system that holds real data?
Send me the system and the use case. You get an assessment of what the scoping would mean, before you commission anything.
How it runs
How this runs
Four steps. After the second it is settled which tools exist and where they stop.
STEP 01
A 30 minute conversation
Which system, which users, which agent on the other side. After that I tell you whether an MCP server is the right instrument here. Sometimes it is a plain interface, and then I say so.
STEP 02
Scoping the tools
The list is drawn up together: what may read, what may write, what has to be confirmed. That list is the acceptance later, which is why it comes before the build and not after it.
STEP 03
Build and connection
Server, sign-in, tools, logging and cost cap, in your environment. Connected to your agent, whether that is Claude, a client of your own or an application you already run.
STEP 04
Handover
Infrastructure in code, a short description of the tools and their limits, and a session with the people who run the server afterwards. From then on it runs without me.
Entry offer
First MCP server in operation. From 3,900 €
Starting price for one connected system with a workable interface. The final price is settled after the scoping and before anything is built.
Not a prototype but a server in operation: after three weeks it runs in your environment, carries the identity of your users through, logs every call and has a cost cap.
What you get
- Scoping the tools with you: what reads, what writes, what has to be confirmed
- An MCP server for one connected system, in your AWS or Azure environment
- Sign-in via OAuth 2 with your existing directory, without a shared technical account
- Writing tools with confirmation and idempotency, so a call sent twice does not take effect twice
- An audit trail over all tool calls, retained and open to analysis, with duration and place settled in the scoping
- Quotas per user and bounded response sizes, giving the calls through the server an upper limit
- Infrastructure as Terraform code, with metrics and tracing, handed over to your team
What you do not get
- No model selection as a project of its own, we decide that in the first conversation
- No interface and no chat client of its own, the server serves the agent you already have. For clients that cannot display prompts back to the user, no confirmation interface of its own is built either
- No connection of several systems and no unlimited number of tools at the starting price: up to six tools are included, each further system and each further tool is quoted beforehand
- No operation in your own data centre at the starting price, AWS and Azure are what the price covers. Self-hosting is quoted separately
- No assessment of whether the use case is permissible under data protection law
- No ongoing support without an agreement of its own
- A documented, reachable interface on the system to be connected, with test access and a contact. Without it, that is a project of its own
- Rights per user in the system to be connected. Where it knows only one technical account, the identity carried through ends at the token broker, and the tool scope draws the line instead
- An existing directory for sign-in, such as Cognito, Entra ID or Keycloak. Amazon Cognito does not support dynamic client registration: for an internal directory with a pre-registered client that is immaterial, but if third-party clients such as Claude Desktop are meant to register themselves, a facade goes in front of it and that is quoted beforehand
- The client in use can display prompts back to the user (MCP elicitation). Otherwise there is no place where a human confirms a writing call
- What is produced sits in your account and belongs to you, including the infrastructure code
- Price net, plus VAT
- You are committed to nothing. Some teams build the second system themselves afterwards
The outcome
What is different afterwards
Rights that are correct
Where the connected system knows rights per user, the agent can do nothing the user could not do themselves. That is then not a setting somebody can forget, it follows from the path the token takes. Where the system knows only one technical account, the identity carried through ends at the token broker, and the tool scope draws the line instead.
An answer for the audit
Who, when, which tool, with which arguments. The question comes up in every company sooner or later, and it rarely comes with notice.
Costs with an upper limit
A quota per user and bounded response sizes turn an open bill into an upper limit you can name in advance. That holds for the calls running through the server; whatever your client bills directly against its own model account sits outside it.
The second server is cheap
Sign-in, logging and operations are built once. Connecting another system after that is legwork and not a second project.
Technologies I use
Technologies I use
Protocol
- MCP
- FastMCP
- JSON-RPC
- Streamable HTTP
Clients
- Claude
- Claude Code
- agents of your own
- OpenAI compatible
Sign-in
- OAuth 2
- Amazon Cognito
- Microsoft Entra ID
- Keycloak
Models
- Amazon Bedrock
- Anthropic API
- Azure OpenAI
Connections
- REST
- GraphQL
- gRPC
- PostgreSQL
- MySQL
Runtime
- AWS ECS
- AWS Lambda
- API Gateway
- Terraform
Operations
- OpenTelemetry
- CloudWatch
- Audit log
Languages
- Python
- TypeScript
- Golang
- PHP 8
Who you are talking to
Directly with me as a freelancer. No agency in between.
I am Tim Rutte. More than 20 years in software development. Today I build the infrastructure agents use to reach real systems. You talk to the person who touches your code, from the first call to the handover.
- 20+years in software development
- 50+successful projects
- 2003working remotely since then
Common questions
Common questions about MCP servers
What is an MCP server?
The Model Context Protocol is an open interface an AI agent can use to call tools: query a database, create a record, read a file. The server is the side that offers those tools. The advantage over a separate integration per agent is that any client speaking MCP can work with it.
We have already built an MCP server. What do you do differently?
Mostly the same, only in the places a prototype is allowed to skip: identity instead of a shared account, confirmation before writing calls, idempotency, logging and a cost cap. If that is already in place at your end, you do not need me, and I say so in the first conversation.
Why is a key in an environment variable not enough?
Because it does not say who is being acted for. A technical account with all rights gives every user all rights as soon as they are allowed to operate the agent. And the log later leads to that account rather than to the person behind it. Both only stand out when it counts.
Does this only work with Claude?
No. MCP is an open protocol, and the server is independent of the client. Claude, Claude Code, agents of your own and other applications speaking MCP all reach the same server. Which client is in use at your end belongs in the first conversation, because the sign-in is built around it.
What does an MCP server cost?
The entry package starts at 3,900 euros net and covers one server for one connected system, in production in your environment, with sign-in, logging and a cost cap. Why a starting price and not a fixed one: the effort is set by the system behind the server rather than by the server. Where there is a documented interface and a test system, the figure holds. Where there is not, you see the final price after the scoping and before anything is built, not in a supplementary invoice. Running it afterwards costs what the infrastructure costs, plus the tokens your users consume.
How do you stop the agent from doing the wrong thing?
In three places. The tool scope limits what is possible at all. Writing calls need a confirmation by a human. And idempotency makes sure a call sent twice does not take effect twice. Anything beyond that, such as text from a ticket trying to steer the agent, belongs in the scoping: tools that can do nothing dangerous are hard to misuse.
Does this have to run in the cloud?
No, but somewhere that somebody runs it. I usually build this on AWS, because sign-in, logging and cost control are available there without extra work. Azure is covered by the starting price just as well. Your own data centre works too, only none of those building blocks is ready there, they get built rather than configured. That is why self-hosting is quoted separately and not at the starting price.
Where does the data sit?
In your account and in your region. The default is eu-central-1 in Frankfurt, another EU region on request. The server, the audit log and the logs do not leave it. The processors are the providers whose services you use anyway: your cloud provider and the provider of the model. With Amazon Bedrock, inputs and outputs are neither stored nor used to train the models; with a different model provider the terms differ, and that belongs in the scoping. Which data processing agreements you need with whom is settled there as well. Your data protection officer decides that, not I.
How long does it really take?
Three weeks for the first server, if the system to be connected has a usable interface and a contact is reachable. Without an interface one is needed first, and then we are talking about a different project. That comes out in the first conversation, not in the third week.
We already have an agent, the costs are just running away. Is this the right page?
Only partly. Whoever still has to get their agent to a system is in the right place here: tools, sign-in, logging and the cap are built together. Whoever already runs the agent and only wants the costs under control belongs on /en/services/reducing-llm-costs/. That is a service of its own with its own entry package, and it is about measurement per operation, prompt caching, context length and the choice of model, not about the connection. If both coincide, say so in the first conversation and we scope it together.
Other services
What else I help with.
AI in production
The infrastructure behind AI systems that actually ship: MCP servers, controlled tool access, LLM integration with real permissions and cost control.
Learn moreIntroducing Claude Code
Make Claude Code productive in your team without eroding the architecture: a spec layer, architecture rules that hold, tests as a condition rather than an intention.
Learn moreReducing LLM costs
FinOps for inference: make cost per operation and per user visible, choose the model by task, keep context and repetition in check. Measure first, then act.
Learn more