An MCP server is the small service that lets an assistant ask your own systems a specific question and get a specific answer: an order’s status, a CMS page, a document the caller may already open, or the state of a support ticket. The assistant does not receive a login to the whole company. It receives a short list of tools, and each tool does one job under the rights of the person who is signed in.
Contents
That is the shape we build. One process, a handful of tools, authentication tied to a real session, the smallest rights that tool needs, and a log of every call. Orders, documents, the CMS and support status stay where they already live. The MCP server is the boundary in front of those systems, not a second copy of the database.
This suits a company that wants an assistant in support, sales or operations, answering from live records rather than from a file pasted into a chat. A chatbot that only talks is a different job, covered in our article on AI chatbot and agent development. Here the subject is which calls exist, who they act for, and which must never run alone.
What an MCP Server Tool Call Does
The Model Context Protocol is an open way for an assistant to use tools on a server you run. The host speaks JSON-RPC to that server. The MCP server lists its tools. The model picks a name and fills in arguments. Your code runs that one function and returns a result. Message rules are in the 2025-06-18 specification.
A tool call is not a chat reply and not a free-form instruction. It is one API request with a fixed name. The model may choose get_order_status and pass an order id. It may not invent a path, open a shell or rewrite the query. If the name is not on the list, nothing runs. JSON Schema on the input says which fields may be sent.
A definition the server can advertise looks like this:
{ "name": "get_order_status", "description": "Read status, total and line items for one order the signed-in caller is allowed to see.", "inputSchema": { "type": "object", "properties": { "order_id": { "type": "string" } }, "required": ["order_id"] } }Keep the description narrow. “Return this order if the caller may see it” is a tool. “Help with orders” is not, because the model will stretch a vague name. Add a tool when a real question repeats, not because it might be useful someday.
A customer asks where order 10482 is. The model sends that id to get_order_status. The server checks the session, loads the order through your API, and returns status, carrier and line items, not the payment token or the margin.
Read Tools and Write Tools on an MCP Server
Split tools by what they change. A read tool looks something up and returns it. A write tool creates or changes something. That split is the main safety decision on an MCP server, and the name should make it obvious.
| Name | Reads or writes | Who may call it |
|---|---|---|
get_order_status | Reads | The customer who owns the order, or the agent on that case |
search_documents | Reads | Staff whose group already has those files |
list_cms_pages | Reads | Editors of that site |
create_reply_draft | Writes a draft only | A support agent; nothing is sent |
send_customer_email | Writes, and sends mail | Nobody automatically; a person approves |
issue_refund | Writes, and moves money | Nobody automatically; a person approves |
Read tools answer the daily questions: order status, documents for a contract, whether a page is published, ticket state. A read of every customer, or of every field, is not a safe read. Return status, dates, titles, a short excerpt and a link into the system the person already uses.
Write tools are fewer. A draft stays in the help desk. Sending email or moving money does not. The model may prepare the draft and the amount. Approval sits outside the model.
The Assistant Is Not a Trusted User
The model is not an employee and it is not an admin. It proposes a tool name and some arguments. The MCP server decides whether that call is allowed for the human who is present. A long-lived admin key reused by every tool is a shared password, not an integration.
Bind the call to a real session. The person signs in with the account they already have. The server checks a short-lived token for that session and calls your API as that person, or as a service account no wider than their rights. When the session ends, so does the token. A copied chat does not open the order system.
Authentication says who is calling. Authorisation says which records they may touch. A prompt that says “only look at this customer” is advice. The check in code is the control.
Scoping Every Call to One Customer
The customer id comes from the session, not from the model. If a shopper is signed in, every tool on the MCP server filters to that shopper. If a support agent is signed in, the filter is the customer on the open case. Documents and the CMS follow the same rule.
The model will sometimes pass an id it saw earlier, or one the user typed. Treat that id as a claim, not as permission. get_order_status loads the order and compares the owner with the session. If they differ, the tool returns a refusal, with no hint that the order exists. Search stays inside the caller’s set, with a small limit.
Put the check in one place and call it from every tool. A new tool that forgets the filter is how a careful design leaks. The model does not get a customer-id field it can set to anyone.
Logs and Human Approval for Email and Money
Every call is logged: who was signed in, which tool, arguments with secrets and card numbers removed, and whether it succeeded. Do not feed that log back to the model. A later call could quote a record the current caller should not see.
Anything that sends email or changes money stops for a person. The tool may draft the message or calculate a refund. A staff member who already has that right sees the recipient, the amount and the order id on your own screen, and confirms. Your existing mail or payment path does the work. The MCP server records the approval and who gave it. If nobody confirms, nothing is sent and nothing is charged.
A confident paragraph is not a signature. “The model sounded sure” is not approval, and the confirmation is not a line hidden in a prompt.
Where an MCP Server Runs
Put the server beside the systems it calls, on the private network they already use. A Node.js or PHP process next to the API is enough for most companies. A local assistant can talk to it over stdio. A shared assistant talks to it over HTTP on an internal address, with the same session checks as the rest of the app. It is not a public URL with a key in a laptop config.
If orders and documents must stay on your network, the model can stay local too. Retrieval covers questions about your text. Live status still comes from a tool, because yesterday’s export is stale by the afternoon.
What Not to Expose
An MCP server should refuse to be a general remote control. Leave these off the tool list:
- SQL the model wrote, or any query on a raw connection string.
- A shell, a view of the whole disk, or a tool that fetches any URL the model names.
- Search across all customers, tickets or documents, with no owner and no limit.
- Card numbers, full payment details, passwords, cookies and raw tokens.
- Admin actions: creating users, changing roles, deleting the catalogue, exporting the database.
- One tool whose only input is free text. That is a prompt with a side door.
When a task needs a new fact, add a named tool with a schema, a permission check and a log line. A short list you can explain is a healthy server. A long list nobody reviews is a wide-open API.
How an MCP Server Differs from Pasting Data into a Chat
A spreadsheet pasted into a chat is a copy. It goes stale, it often includes rows that person should not have shared, and nothing records who pasted it.
An MCP server answers at the moment of the question, from the system of record, and only with the fields that tool may return. The caller sees their own orders, not an export of the company. A change is a named action with a person in the loop, not a sentence someone might carry out later by hand.
The chat is where people ask. The server is where an answer is allowed to come from, including a refusal when the question is cleverly worded.
How We Work
- Discovery. We map where orders, documents, CMS content and support status live, who may see each, and which actions must wait for a person.
- Tool list. Names, inputs, read or write, and who may call each tool. You agree the list before we build.
- Build. We implement one MCP server in Node.js or PHP against your API, with session auth, a per-customer filter and structured logs.
- Test. Allowed calls, refused calls, a caller passing someone else’s id, and the approval step for mail and refunds.
- Launch. The server stays on your network, the assistant points at it, and staff get a short note on what a refusal looks like.
- Support. We add a tool when a real task needs it, and remove a tool that should not have been there.
Why CodeWiz
- A studio built for this stack. CodeWiz was founded in 2023 by Dragan Plavšić in Banja Luka. We work with clients locally and abroad, remotely.
- APIs and auth first. Tools call the APIs and permission checks you already rely on. We build those in Node.js and PHP when they are missing.
- AI that can stay on your network. Retrieval over your documents, and local models when text should not leave, sit beside the live tools. That is part of our AI and ML integration services.
- A small MCP server you can review. We would rather explain six tools than point a catalogue of public connectors at production.
- Open source first. The protocol is open, the server is yours, and the design follows how your staff already work.
Frequently Asked Questions
Does the MCP server have to sit on the public internet?
No. It belongs on the private network beside your API. One staff machine can use a local process. A shared assistant uses an internal HTTP address and the same login as the app. Open it publicly only for a client outside that network, with the same authentication as any other public API.
Can it email a customer or refund an order by itself?
No. It may draft the email or compute the amount. A person who already has that right confirms, and your existing mail or payment path does the rest. Without that confirmation, the action does not happen.
How is this different from putting an API key in the prompt?
A key in the prompt is a secret the model can repeat or use for anything that key allows. Here the model never sees the credential. It sees tool names. The server holds the credential, ties it to the signed-in person, and refuses anything outside that person’s rights.
Which of our systems can it reach?
Orders, documents, a CMS or a help desk, wherever a narrow function can sit in front of an API. Each becomes one or two tools. If there is no stable interface yet, building it is part of the work.
What do you need from us before you start?
Someone who knows where orders, documents and tickets live, and who may see them. A staging API, or the code if we are building it. The daily questions, and the actions that must wait for a person. We estimate after that conversation.
A Server Your Staff Can Explain
Tell us which question your team looks up all day, and which system holds the true answer. We will propose one MCP server, the tools it should have, and the calls it must refuse. Contact us, or see the wider set of development services.