How to Build a Simple Read-Only MCP Server for Your Store

To build a simple MCP server for a store, pick two or three read-only questions, wrap them as tools with typed inputs, connect them to your shop's API with a restricted key, and test on staging. A first version can be small. This article gives the steps and a short pseudo-code sketch, not production code.

Before you start

You need three things:

• A shop with an API. WooCommerce and Shopify both offer APIs. Check the current documentation of your platform for the exact calls.
• An MCP SDK. Anthropic and the community maintain official SDKs for several languages, including TypeScript and Python. Check the official MCP documentation for the current list.
• A staging copy of your shop. Do not test on live data.

Step 1: Choose a narrow scope

Write down what the server should answer. Keep the list short. For a first version, these three are enough:

• Search products by text.
• Get one product by SKU.
• Get the status of one order by order number.

Everything else can wait. A small tool list is easier to secure and easier for the AI model to use correctly.

Step 2: Create a restricted API credential

Do not reuse your admin login. Create a dedicated credential for the server.

• Give it read-only permission on products and orders.
• Do not give it access to customers, settings or payments unless a tool needs it.
• Store the key in an environment variable or a secrets manager, not in the code.
• Make it easy to revoke.

If your platform cannot limit a key to read-only, put a thin layer in front. The layer allows only GET requests.

Step 3: Define each tool

A tool needs a name, a short description and an input schema. The AI model reads the description to decide when to call the tool. Write descriptions in plain words.

Good tool design rules:

• One tool, one job.
• Name tools after what they do, such as get_order_status.
• Validate every input. Reject anything outside the schema.
• Return only the fields the question needs.
• Limit result sizes, for example a maximum of 20 products per search.

Step 4: Write the handlers

A handler receives validated input, calls the shop API, and returns a trimmed result. Here is a pseudo-code sketch. It is not tied to one language or SDK.

server = new McpServer(name = "my-store", version = "0.1.0")

tool "search_products":
  description: "Search products by text. Returns up to 20 results."
  input:  query (string, 1 to 100 chars)
          limit (integer, 1 to 20, default 10)
  run:
    validate(input)
    rows = shopApi.get("/products", search = query, per_page = limit)
    return rows.map(p => id, sku, title, price, in_stock)

tool "get_order_status":
  description: "Get status and shipping state of one order."
  input:  order_number (string, matches digits only)
  run:
    validate(input)
    order = shopApi.get("/orders", number = order_number)
    if not order: return error("Order not found")
    return status, created_at, shipped_at, item_count, total
    // No name, no address, no email.

start server on stdio

Note what the sketch leaves out. The order tool returns no customer name, address or email. That is a design choice, not an accident.

Step 5: Choose a transport

MCP defines how client and server talk. Two common options:

• stdio. The AI app starts your server as a local process. It suits tools on your own computer.
• HTTP-based transport. The server runs as a web service that many users can reach. It needs proper authentication, such as OAuth. Read the authorization section of the MCP spec before you build this.

For a first test, a local stdio server is simpler. Move to a hosted server only when you have a clear need.

Step 6: Test with a client

Test the server before you connect it to a real workflow.

1. Use an MCP inspector tool, or a client you trust, to list your tools.
2. Call each tool by hand with normal inputs.
3. Call each tool with bad inputs, such as empty strings, very long strings and special characters. The server should reject them cleanly.
4. Ask an AI app a few plain questions. Check whether it picks the right tool.
5. Compare the results with what the shop admin shows.

Run all of this against staging.

Step 7: Add logging

Log every tool call with a timestamp, tool name, input and result size. Do not log secrets. Think about personal data in logs as well. Review the logs after the first week. They show what the AI asks for and where it gets confused.

Step 8: Plan the next step

Once the read-only server is stable, you can decide about more. Before you add a write tool, read the security checklist and plan human approval. A write tool such as a refund needs limits, approval and an audit trail.

A final checklist

• Scope is two or three read-only tools.
• The API key is dedicated and read-only.
• Inputs are validated.
• Results are trimmed and capped.
• No personal data is returned unless a task needs it.
• Every call is logged.
• Tested on staging first.

Frequently asked questions

Which programming language should I use?

Use the one your team already knows, as long as an MCP SDK exists for it. TypeScript and Python are common choices. The language matters less than the tool design.

Do I need to host the server publicly?

No. A local server using stdio works for one user on one machine. Host it as a web service only if several people or remote AI apps need it. A hosted server needs authentication and more careful security.

Can I let the server write to my shop?

You can, but start read-only. Add write tools later, one at a time, with narrow scope, limits and human approval for important actions.

How long does a first version take?

It depends on your platform and experience. A small server with a few read-only tools is usually a modest project. Testing and security review often take more time than the code.