Hiring someone to build an MCP server: what to put in the brief

The short answer

An MCP server lets an AI assistant such as Claude or ChatGPT use one of your systems: look up an order, read a ticket, add a row. If you are new to the idea, what an MCP server is explains it in plain words. This guide is about the order you place.

The most important line in the brief is not the technology. It is the list of actions. Every tool you put on the server is something the assistant can do in the middle of a conversation without asking you again. So the brief should name each action, say whether it only reads or also changes something, say whose login sits behind it, and describe the test you will run before paying.

Write those eight things down and the quote gets specific. Leave them out and you will be quoted for “connect AI to your system”, which can mean anything.

Why this brief is different from a chatbot brief

A chatbot brief is mostly about answers: what it knows, what it must refuse, when it hands over to a person. The chatbot and AI agent brief covers that well, and its “Actions” and “Accounts and data” fields are where an MCP server starts.

An MCP server brief is about access. The protocol documentation describes the server as offering three kinds of things to the assistant: tools (actions), resources (information to read) and prompts (ready-made instructions). The assistant gets the list of tools with a name, a description and the inputs each needs, and decides for itself when to call one.

That last part is what buyers miss. With a normal automation, a person or a fixed rule decides when the step runs. With an MCP server, the model decides. So the limits have to be in the server itself, not in a hope that the assistant will be careful.

The eight fields to put in the brief

Fields 3 and 4 are the scope. If a seller’s quote does not repeat your tool list back to you, ask them to.

Write tools: the error that is not an error

If any tool changes something (sends a message, creates a record, posts something), add one more sentence to the brief: before retrying a write that returned an error, check whether it happened anyway.

This comes from a publishing job of mine. Over two days in August 2026, the platform’s API answered several publish requests with errors. My job treated them as failures and retried. Five posts were recorded as failed; all five were already live. The job was retrying finished work, and its own record of what was published no longer listed them. The fix was a rule: on an error, look up the account first, and only count it as a failure if the post is not there. The full story is in what “safe to re-run” means.

An AI assistant calling a write tool is in the same position, with one extra risk: it may simply try the tool again because the first answer looked like a failure. So the server should do the checking, not the assistant. Ask the freelancer how each write tool avoids doing the same thing twice.

Credentials: the login that expires quietly

Field 5 matters twice: once for safety, once for keeping it running.

For safety, the server can do whatever its credential can do. A key that can delete records gives the server the power to delete records, even if no tool is meant to. Ask for a key with the narrowest permissions that still work. The guide to who owns the accounts covers the general rule.

For running, logins expire. The protocol documentation recommends OAuth for remote servers, the “sign in and allow” flow, and those sign-ins can lapse and need reconnecting. In September 2026 a token behind one of my scheduled publishing jobs became invalid. Five publishing slots in a row went out empty over two days. The scheduled task itself reported success each time, the catch-up step treated the error as permanent and did nothing, and my watchdog did not check the login. I wrote that one up; the change was a daily check of the login itself plus an immediate alert when it fails.

For an MCP server, the same failure looks like this: the assistant says “I could not reach the order system” to whoever is asking, and nobody tells you. Put in the brief: when the server’s credential stops working, I get an alert, not just the user.

Cost: put a ceiling in the brief

Two costs come with an MCP server after delivery: hosting, if it is remote, and usage, because every tool call is part of a conversation with a paid AI model. The running costs after handover guide lists the usual lines.

Limits matter here too. One of my overnight content jobs hit a monthly spending limit on the account it ran on. It produced its output, then ended with an error, and another job sharing that account would have hit the same wall. A server that lets an assistant loop through tool calls can reach a limit faster than you expect. Ask for:

• the expected cost per hundred uses, in the freelancer’s estimate;
• a spending limit set on your AI provider account;
• what the assistant tells staff when that limit is reached.

Prices for chatbot and agent work on the AI chatbot and agent page start from $100 to $1,000 for a basic package and rise with live integrations, which is what an MCP server is. Expect a server with write tools and hosting to be quoted above a read-only one.

Acceptance: test the edges, not the demo

A demo shows the assistant answering a good question. Acceptance should show what happens at the edges.

Test 2 is where weak builds show. If the server offers a broad “run any query” tool, the assistant can do things the brief never mentioned. Narrow tools are easier to test and safer to keep.

A brief you can copy

Job: Staff ask the assistant [question]; it looks up [system] and answers. System and access: [system], via [API / read-only user]. Docs: [link]. Tools: 1) [name]: returns [fields], read only. 2) [name]: [creates/changes X], asks for confirmation first. Never: delete, change prices, anything not listed above. Credentials: a key I create with only these permissions; I can revoke it. Runs: [locally for one person / hosted on my account for N staff]. Logging: every tool call with inputs, time and result, readable by me. Errors: write tools check whether the action happened before retrying. If the credential fails, I get an alert. Acceptance: the six tests above. Maintenance: rate and response time for fixes after delivery.

Paste it into your first message, with your own system and tool names, and ask the seller what they would change. A good answer will narrow the tool list, not widen it.