The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in late 2024, that lets AI applications connect to external tools and data through a common interface. An MCP server exposes tools, resources and prompts; an MCP client, such as Claude, ChatGPT, Cursor or VS Code, uses them. Moving MCP from pilot to production means limiting scope, securing authentication, controlling permissions, logging every call and assigning an owner.
What problem does MCP solve?
Before MCP, each AI assistant needed its own custom integration for every tool: one connector for the CRM, another for the analytics platform, another for the file store. MCP standardises the connection. Build one server for your CRM and any MCP-compatible client can use it.
Adoption spread quickly. OpenAI, Google, Microsoft and many developer tools added MCP support, and companies such as GitHub, Stripe, Atlassian and HubSpot have published MCP servers for their products. For marketing teams this means assistants that can read campaign data, query a database or update a project board directly.
How does an MCP setup fit together?
There are three parts. The host is the application the user works in. The client inside it maintains a connection to each server. The server wraps a system and describes what it offers: tools the model can call, resources it can read and prompt templates.
Servers can run locally on a user’s machine, communicating over standard input and output, or remotely over HTTP. Remote servers are what most production deployments use, because they can be secured and monitored centrally.
Stage 1: pilot checklist
Start narrow so you learn without exposing much.
- Choose one use case, such as letting an assistant read Google Analytics 4 or Search Console data for reporting.
- Prefer an official server from the vendor where one exists over a community one.
- Give it read-only access first.
- Test with a small group of named users.
- Write down what success looks like: questions answered correctly, time saved on a report.
Community servers vary in quality and maintenance. Read the code or at least the permissions it requests before installing one.
Stage 2: security and authentication
MCP’s specification includes an authorisation framework based on OAuth for remote servers. Use it rather than pasting long-lived API keys into configuration files. Each user should authenticate as themselves, so the server enforces that person’s existing permissions.
Also consider prompt injection. If a server returns content from emails, web pages or documents, that content can contain instructions aimed at the model. Treat tool outputs as untrusted data, and design the host to ask for confirmation before any write action triggered by them.
Stage 3: define permissions tool by tool
Each tool a server exposes is a permission. Review them one by one:
- List every tool and mark it read or write.
- Remove tools nobody needs; fewer tools also help the model choose correctly.
- Require human confirmation for write tools, such as sending email, changing budgets or deleting records.
- Restrict sensitive data with filters on the server side, not just instructions to the model.
- Document the decision for each tool, with the date and owner.
Stage 4: logging and monitoring
In production you must be able to answer: who called which tool, with which arguments, and what came back. Log calls on the server, mask personal data, and keep logs long enough for audits. Monitor errors and latency, since slow tools make assistants feel broken.
Alerts are useful for unusual patterns, such as a sudden spike in write calls or calls outside working hours.
Stage 5: testing and change control
Treat servers like any other software. Version them, test tool behaviour automatically, and review changes before deploying. When you change a tool’s description, test again with the clients your team uses; models choose tools based on those descriptions, so wording changes can change behaviour.
Evaluate with real tasks
Build a set of 30 to 50 realistic requests, such as “compare last month’s organic sessions with the previous month by landing page”. Check that the assistant calls the right tools, with sensible arguments, and produces a correct answer. Repeat after every server or model change.
How Alien Road applies MCP in AI optimisation work
In a typical engagement, discovery lists the systems the client’s marketing team reads most often for reporting and decisions: analytics, ad platforms, CRM, content management. The team checks which have official MCP servers and which would need a custom one.
Setup starts with read-only servers for reporting tasks and named users. Custom servers, where needed, are written with a minimal tool list, OAuth authentication and server-side logging, and stored in the client’s repository. Write tools are added only after the read-only phase has run cleanly.
Measurement covers the evaluation set results, time spent on recurring reports before and after, tool call error rates and any security events. Monthly reporting includes a sample of logged sessions, so the client can see exactly what the assistant accessed.
Stage 6: production readiness checklist
Before going live widely, confirm:
- Each server has a named owner and a maintenance plan.
- Authentication is per user, with no shared keys in config files.
- Write tools require confirmation.
- Logs capture calls with personal data masked.
- The evaluation set passes on current client versions.
- Users know which servers are approved and how to request new ones.
The last line matters because users can often add servers themselves. An approved list keeps unknown community servers out of sensitive environments.
How do you choose between official and custom servers?
Official servers are maintained by the vendor, follow its API changes and usually support proper authentication. Use them whenever they cover your needs. Their drawback is scope: they may expose more tools than you want, so check whether the client lets you disable individual tools.
Custom servers make sense when no official one exists, when you need to combine several systems into one simple tool, or when you must enforce filters the vendor server lacks. They also become your maintenance burden. Keep them small, documented and versioned, and plan for someone to update them when the underlying API changes.
Where to start this week
Pick one recurring report your team builds by hand from a single system. Find that system’s official MCP server, connect it read-only to the assistant your team already uses, and ask it to produce last month’s version of the report. Compare with the manual one. Write down the errors and the time saved, and use those notes to decide on stage two.
Keep reading: AI Optimization · AI Optimization