By KYN AI Advisory Team — AI implementation specialists, Singapore
MCP, the Model Context Protocol, is an open standard that lets an AI application connect to tools and data through one common interface. Instead of writing a custom link for every pairing of model and system, you expose your system once as an MCP server, and any compatible AI application can use it. For an SME, it lowers the cost of connecting an agent to your CRM, ledger or files. It also creates a new door into your data, so the controls matter more than the protocol.
What is MCP?
The Model Context Protocol was introduced by Anthropic as an open specification and is now supported by many AI applications and developer tools. It defines how an AI application, called the client, talks to a program that offers capabilities, called the server.
A server can offer three kinds of thing:
- Tools. Actions the model can request, such as "create an invoice draft" or "search customers".
- Resources. Data the model can read, such as a file or a record.
- Prompts. Reusable instructions or templates.
The model does not touch your system directly. It asks the client, the client calls the server, and the server runs your code and returns a result. Your code decides what is allowed.
Why does it matter for a small business?
Before a shared standard, connecting an AI application to a system meant writing a one-off integration for each pair. Ten systems and three AI applications meant up to thirty links. With MCP, each system gets one server, and each application gets one client.
Some vendors now publish MCP servers for their own products. Whether a given server is mature enough for production is a case-by-case check.
For you, the effect is practical:
- Faster connections to systems that already publish a server.
- Less lock-in to one AI application, because the tool layer stays yours.
- A single place to apply rules, logging and limits.
How is MCP different from an API?
An API is the interface a developer codes against. MCP is a layer on top that describes tools in a way a model can discover and use without custom code per tool.
| | Typical API | MCP server | |---|---|---| | Audience | A developer writing integration code | An AI application choosing tools at run time | | Discovery | Read the documentation | The client lists the tools and their descriptions | | Who decides to call | Your code | The model, within what the server allows | | Wraps | Your database or a service | Usually an existing API |
An MCP server often wraps an API you already have. It does not replace it.
What are the risks?
A model choosing tools is a new decision-maker inside your system. Four risks are worth naming.
- Over-broad tools. A server that exposes "run any query" lets a model run any query. Expose narrow tools instead: "get invoice by number".
- Prompt injection. Text a tool returns, such as an email body or a web page, can contain instructions aimed at the model. Treat returned content as data, never as commands. See prompt injection in business AI agents.
- Shared credentials. If every user's agent calls the server with one service key, you cannot tell who did what. Use named identities.
- Untrusted servers. A third-party server runs code with whatever access you grant. Review it like any dependency before connecting it to real data.
Which rules should every MCP server follow?
These are the rules we apply when we build one.
- Least privilege. Each tool does one thing and checks the caller's permissions.
- Named identity. The server receives who is asking, and the database applies row-level security for that user.
- Read and write apart. Read tools and write tools are separate, and write tools are off unless needed.
- Human gate. Tools that send a message, move money, file a document or delete data return a pending request. A named person approves it. See approval gates for high-risk agent actions.
- Logging. Every call is written with the actor, tool, inputs and result.
- Limits. Rate limits and size limits stop a loop from running up cost or flooding a system.
Do you need MCP now?
Probably not for a first agent. If you control both ends, a direct function call from your agent to your own API is simpler and easier to secure. MCP pays off when you want several AI applications to use the same tools, when you want to adopt a vendor's published server, or when your team wants to use a general-purpose assistant against company data without a custom build.
Our view: build the tool layer as clean, narrow functions first. Wrapping them in MCP later is a small step. Wrapping a messy layer in MCP only makes the mess easier for a model to reach.
What does an MCP server expose in practice?
Take a company that wants an assistant to answer questions about orders (illustrative). The MCP server offers three tools and nothing else.
| Tool | Does | Does not | |---|---|---| | find_order | Returns one order by number | Search across customers | | list_open_orders | Returns open orders for one account | Return prices or margin | | draft_status_note | Writes a draft message | Send it |
The assistant can ask a question, call a tool and show the answer. It cannot reach the database directly, cannot see other accounts and cannot send a message. A person sends the note.
Before you connect a server, ask four questions: who runs it, what data leaves your account, what is the narrowest permission it needs, and where is each call logged. If the answers are vague, wait. A narrow tool you can describe in one line is far easier to defend than a general one.
How do you review an MCP server before connecting it?
Treat a new server like a new supplier. Read its documentation and list every tool it offers. Check whether the tools can write or only read. Look at who maintains it and how often it is updated. Run it first in a test account with sample data, and watch the calls it makes. Confirm that credentials are scoped to the minimum and that you can revoke them in one step. Log each call with the actor and the time. Record the review in a short note, with the date and the reviewer, and repeat it whenever the server changes version. This takes an hour and avoids the situation where nobody knows what an assistant can reach.
Where KYN fits
KYN builds the system underneath: cloud infrastructure in the client's own account, a front end around the team's workflow, and agents with rules-based logic. Where an MCP server helps, we expose narrow tools over the client's own data. Agents have their own restricted accounts, the database uses row-level security, and every action is logged with the actor. Outbound messages, money, filings and deletions wait for a named person.
The first 14 days are a review of your stack and interviews with your team. A full build ships in under 90 days. See integrations and security.
Frequently asked questions
Is MCP the same as an AI agent?
No. MCP is a connection standard. An agent is software that decides what to do and uses tools to do it. An agent can use MCP tools, or call your API directly.
Is MCP safe to use with company data?
It can be, if the server is narrow, identity-aware and logged. It is unsafe when it exposes broad queries, shares one credential across users or sends returned text to a model without treating it as untrusted.
Can I connect MCP to my accounting or CRM software?
If the vendor publishes a server, you can try it, after reviewing the scopes it asks for. If not, a custom server over the vendor's API gives you control over exactly which actions exist.
Checked 30 October 2026.
Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.
