Att få en MCP-server att köra i en utvecklingsmiljö är okomplicerat. Att få den att överleva verklig användning - riktiga agenter, riktig data, riktig trafik - är där de flesta team lär sig svåra läxor.
Här är vad som skiljer demon från produktion.
1. Avgränsad, återkallningsbar autentisering på varje tool-anrop
Varje förfrågan till din MCP-server bör bära en autentiseringsuppgift, och den uppgiften bör verifieras innan något tool körs. Servern bör veta vilken agent som anropar, på vems vägnar, och vad den får göra.
Det betyder:
- API-nycklar eller OAuth-tokens på varje förfrågan, inte en enda delad hemlighet
- Behörighetsomfång per tool - en rapporteringsagent kan anropa
get_revenue_datamen intedelete_record - Återkallningsbarhet - du kan stänga av en agent som beter sig illa utan att ta ner allt annat
Om din server just nu litar på vilken anropare som helst som träffar rätt endpoint har du byggt ett demo, inte ett produktionssystem.
2. Strukturerade felsvar agenten kan resonera kring
Agenter kraschar inte när de får ett fel - de försöker hantera det. Om dina felsvar är ostrukturerade strängar eller råa stack traces har agenten inget att jobba med och kommer antingen hallucinera en fix eller loopa i oändlighet.
MCP definierar ett felformat. Använd det. Returnera:
- En maskinläsbar felkod (
RECORD_NOT_FOUND,PERMISSION_DENIED,RATE_LIMITED) - Ett människoläsbart meddelande agenten kan väva in i sitt resonemang
- Inga interna detaljer (stack traces, SQL-frågor, filsökvägar) som kan läcka implementationsinformation
Strukturera dina fel som om du designar ett API - för det gör du.
3. Observerbarhet på varje tool-anrop
I produktion behöver du veta vad dina agenter gör. Inte bara att ett tool anropades - utan vilken agent som anropade det, med vilka argument, vad det returnerade, och hur lång tid det tog.
Logga som minimum:
- Tool-namn och indataargument (sanerade - dölj PII innan loggning)
- Agent-identifierare
- Svarsstatus och storlek på utdata
- Latens
I bästa fall dirigerar du in det här i din befintliga observerbarhetsstack (Datadog, Grafana, vad du än använder). Spårningar av tool-anrop är den enskilt mest användbara felsökningsytan när en agent gör något oväntat. Utan dem gissar du.
4. Sträng indatavalidering och sanering av utdata
Din MCP-server är en ny attackyta. Agenter kan manipuleras till att skicka felformad indata, och din server bör inte föra vidare de felen in i dina nedströmssystem.
Validera varje indata mot dess schema innan exekvering. Avvisa tool-anrop med saknade eller felformade argument direkt, med ett rent fel, innan du rör någon data. På utdatan, sanera allt som returnerar användargenererat innehåll innan det går tillbaka till agenten - du vill inte att prompt injection som lever i din databas ska flöda tillbaka in i modellens kontext.
Det här är grundläggande, och det hoppas ofta över i prototypfasen. Hoppa inte över det.
5. Rate limiting per agent och per tool
Utan rate limiting kan en enda felkonfigurerad eller skenande agent uttömma dina nedströms-API:er, mätta din databas, eller bara generera en förvånansvärt stor räkning.
Applicera gränser på två nivåer:
- Per agent - hur många förfrågningar kan en enda agent göra per minut?
- Per tool - dyra operationer (fritextsökning, externa API-anrop, komplexa aggregeringar) bör ha lägre gränser än billiga
Implementera det här på MCP-servernivå, inte bara på nedströmssystemet. Du vill att agenten ska få ett rent RATE_LIMITED-fel med en retry-after-header, inte en timeout från en överbelastad databas.
Den gemensamma nämnaren
Varje punkt på den här listan är ett grundkrav för vilket produktions-API som helst. Anledningen till att team hoppar över dem på MCP-servrar är att prototypfasen går så snabbt - du kan ha något fungerande på en dag - och det är frestande att kalla det klart.
Gör inte det. En MCP-server är infrastruktur som agenter kommer att vara beroende av. Behandla den därefter.
Om du hellre vill ha det här gjort rätt än gjort snabbt och fixat senare, bygger vi produktionsklara MCP-servrar med allt det här inkluderat från dag ett.