MCP Server Instructions: What They Tell an AI Client

Server instructions are text an MCP server can return during initialization to hint at how an AI client should use its tools. They are optional, advisory, and always subordinate to what the client's own rules and the user's system prompt already say.

Understanding instructions helps you write useful ones for a server you build and avoid confusion when a server's guidance conflicts with your project's rules. Tools like fenbs keep the project instructions that people have agreed on separately, so every connected AI reads the human-approved version first.

Where server instructions appear in the protocol

When a client sends an initialize request, the server responds with its name, version, capabilities, and an optional instructions field. That field is a plain text string. A client that wants to surface the guidance can include it when it builds the context for the AI, but the spec does not require it to do so.

Instructions are part of the server's optional capabilities, not required behavior. A server that omits the field entirely is fully compliant. See the mcp server spec for the full list of required versus optional behaviors.

What server instructions are for

Server instructions are meant to give an AI client useful context about the domain the server covers. A calendar server might say that dates are always returned in ISO 8601 format. A code review server might say which severity levels its analysis tool uses. A database server might note that its query tool is read-only.

Think of them as the README for a tool library. They explain what the server does well, how its outputs are structured, and any conventions a caller needs to know before it starts making calls. They are not user rules, not security controls, and not a substitute for clear tool descriptions.

How instructions differ from tool descriptions

Every tool a server declares has its own description string, plus a JSON Schema for its input parameters. Tool descriptions explain what a single tool does, what each parameter means, and what the output looks like. Server instructions are for the server as a whole.

If you find yourself writing the same context in every tool description, it is a good candidate for the server-level instructions instead. If you find yourself writing something that only applies to one tool, keep it in that tool's description.

Why client rules take precedence

The MCP specification is clear that instructions from the server are lower priority than the client's own system prompt and any instructions the user has set. The client decides how much weight to give server guidance.

This matters practically: if your team has agreed that all financial data must be treated as confidential, that rule belongs in your AI client's settings or your project's instructions — not in a server you may not control. A server instruction can be overridden by any client that chooses to; a rule in your own system prompt is under your control.

fenbs Decisions and rules are one place to store the instructions that belong to your project. Every AI app connected over MCP reads those rules first in its context, before any server's optional guidance.

Writing useful server instructions

Keep instructions short. A paragraph that explains the server's domain and two or three formatting conventions is enough. Long instructions compete with tool descriptions and the user's actual task for the client's attention.

• State what domain the server covers and what problem it solves.
• Note any output format conventions an AI needs to interpret results correctly.
• Mention limits that are not obvious from the tool schemas (read-only access, rate limits, required parameters that do not appear in the schema).
• Keep it factual. Do not use instructions to prompt an AI to behave in a particular personality or to override user preferences.

Avoid writing instructions that duplicate what a careful tool description already says. If each tool is well-documented, the server instructions can be brief.

When server instructions cause problems

The most common problem is instructions that conflict with the client's existing rules. Say a server's instructions tell the AI to always respond in Spanish, but the user's system prompt says to respond in English. Most clients will follow the user's instruction, but the conflict produces unpredictable behavior across different clients.

A subtler problem is instructions that claim more authority than the spec gives them — for example, telling the AI it must not answer questions outside a particular domain. That phrasing may work in some clients and be ignored in others. Write instructions as guidance, not commands.

If a server you are connecting to has instructions that conflict with your project rules, the fix is to make your project rules explicit in the place you control: your client's system prompt or your shared Decisions and rules in fenbs.

How to do this with fenbs

1. Create a free account and add a project for the AI work you want to govern.
2. Write the instructions that matter to your project as Decisions and rules. Name the person who agreed to each one.
3. Connect your AI app to fenbs over MCP from Integrations. At the start of each session, the app reads your rules first.
4. When a server you connect provides instructions, check whether they agree with your project rules. If they conflict, update your rules to be explicit about what takes precedence.
5. Store good server instructions you rely on as context notes in fenbs, so the next AI session starts with that knowledge even when the server is not connected.