Can AI assistants use your product? How to make it agent-ready

Who this is for

You run a web product, an online shop, a booking system or an internal tool, and your customers or your team have started to ask an AI assistant to do things in the tools they use. Maybe someone asked whether your product works with their assistant. Maybe you want to be the product that does.

You do not need to know AI to start. The first steps are decisions and checks. Building the interface itself needs a developer who knows your product’s API.

What “agent-ready” means

An AI assistant cannot click through your website the way a person does. It needs a defined list of actions it may take, with a clear description of each one. The open standard for that list is the Model Context Protocol (MCP), described by its authors as a USB-C port for AI applications: one standard way to connect them to data sources, tools and workflows.

In MCP, your product runs a server that offers tools. The assistant asks the server for the list of tools and then calls the ones it needs. According to the tools specification (version 2025-06-18), each tool has a unique name, a description and a JSON Schema for its input, and tools are meant to be controlled by the model, with a person able to deny calls. “Agent-ready” therefore means: a small, well-described set of tools, protected by the same access rules as the rest of your product.

How to tell what you need

• You have no API at all. Start there. An agent interface wraps what your product can already do through an API, so build and document the API first. Go to step 2.
• You have an API but nobody outside uses it. You can start now. Go to steps 1, 3 and 4.
• Customers already ask for a connection to their assistant. Pick the one workflow they ask about most. Go to step 1.
• Your product changes money, orders or customer data. Plan the permissions and confirmations before anything else. Go to steps 5 and 6.
• You only want your website found and described correctly by AI search. That is a different, smaller job: clean structure and structured data. It does not need an MCP server.

Steps

1. Pick one workflow, not the whole product. Write down the one question or task an assistant should handle for your customers, for example “where is my order?”, “what is still open on my account?” or “book me a time next week”. Choose one that has a clear start and a clear result. A narrow first workflow is faster to build, easier to test and easier to explain to a customer.

2. Check that you have a documented API. List the API calls behind that workflow. If they exist, check that they are documented and that a test fails when the documentation drifts from the code. If they do not exist, that is the first piece of work. An agent interface is a thin layer on top of the API, so a weak API makes a weak agent interface.

3. Start with tools that only read. Begin with tools that look things up and change nothing. They are the safest to offer, and they already cover many useful questions. Add tools that write only after the read-only ones have worked in real use for a while.

4. Name and describe each tool for a model, and keep the list short. Give each tool a plain name, a description that says when to use it, and an input schema with only the fields it needs. Keep the number of tools small. A short, focused list is easier for an assistant to choose from than a long one with overlapping tools.

5. Tie access to the logins and limits you already have. The tools should act with the caller’s own permissions and see nothing the caller could not see in your product. The specification requires servers to validate all tool inputs, implement access controls, rate limit tool calls and sanitize tool outputs. Use the same tokens or logins as your API, and never give the assistant more than a person in that role would have.

6. Keep a person in the loop for anything that changes something. The specification says there should always be a human able to deny a tool call, and that applications should ask for confirmation on sensitive operations. For your product this means: anything that changes data, sends a message to someone or spends money needs the user’s explicit approval, and every such action can be traced afterwards.

7. Return clear errors. MCP separates protocol errors, such as an unknown tool, from errors in what the tool did, which are returned in the result with isError set to true. Write the error text so that an assistant can recover from it, for example “no order with that number” rather than “error 500”.

8. Log what the assistant did. Record which tool was called, by which account and when, without storing the private content of the requests. Clients are advised to log tool usage too, but your own log is the one you can rely on.

9. Test with a real AI client and a real person. Connect the server to an AI application that supports MCP and ask your workflow question in plain words. Then watch a customer or colleague do the same. Note where the assistant picks the wrong tool, and fix the descriptions before you add features.

10. Write down how to connect, and keep the interface current. Publish a short page with the address of the server, how to get access, and the list of tools and what they do. Check the list whenever the product changes. The specification also lets a server announce when its tool list changes.

When to get help

Bring in someone experienced if:

• you have no documented API yet, or it is not reliable enough to build on
• the workflow changes data, orders or money, and you want the permissions and approvals reviewed
• you serve many customers from one system and need each of them to see only their own data
• you want the interface to run on a platform you already use, such as Cloudflare, without paying for more than you need
• a customer or partner is waiting for a connection and you want a working version with a fixed price and delivery date first