System Prompts and MCP: Instructions, Tools, and Trust

A system prompt and MCP (Model Context Protocol) are two different ways of shaping what an AI assistant knows and can do in a session. The system prompt carries instructions that arrive before the conversation starts: who the assistant is, what rules it follows, what it should prioritize. MCP adds tool-calling ability: the assistant can read live data, write to external systems, and call APIs during the session. Tools like fenbs use MCP so that shared project decisions and context — the kind of thing that belongs in a system prompt — can instead live in a place that is always current and readable by any connected tool.

This article explains how system prompts and MCP relate, where the trust boundaries sit, and how to decide what belongs in a prompt versus what belongs in a connected tool.

What a system prompt does

The system prompt is the first message in a conversation, submitted before the user speaks. It sets the assistant's behavior for the session: its persona, the constraints it should respect, the format it should use, and any background knowledge it should treat as established. In most AI clients, the system prompt is invisible to the user; it shapes the responses without appearing in the conversation.

System prompts have limits. They are static for the session: if the project state changes, the system prompt does not. They have a length limit: a long prompt with extensive project context uses up context window space that could hold conversation. And they are defined per-session, which means every new session requires the same context to be re-injected, either manually or through automation.

What MCP adds

MCP is a protocol that lets an AI client call tools on external servers during a session. Instead of putting all context into the system prompt up front, the assistant can call a tool to read the current project state when it needs it. The result comes back into the conversation and the assistant uses it in its response.

This changes how you manage context. Rather than maintaining a system prompt that describes the current project, you maintain a project record in fenbs. The assistant reads it through MCP at session start. When decisions change or tasks progress, you update fenbs. The next session reads the current state without any system prompt editing.

How system prompts and MCP work together

System prompts and MCP are complementary, not competing. The system prompt handles things that are genuinely stable: the assistant's role in this context, the format it should use for responses, standing rules that never change. MCP handles things that change: current tasks, recent decisions, where the last session ended.

• Put in the system prompt: the assistant's persona, stable formatting rules, standing constraints, instructions for using tools.
• Put in MCP-backed context: current project state, recent decisions, task list, where the work stands.
• A system prompt can instruct the assistant to always read project context from fenbs at session start — this is a stable instruction that enables dynamic context.
• Avoid putting large blocks of project state in the system prompt: it goes stale and wastes context space.

Trust boundaries between prompts and tools

When an assistant uses MCP tools, it receives content from external sources. That content arrives as tool results, not as part of the original system prompt. This matters for trust: the system prompt carries the instructions the operator wrote deliberately; tool results carry data that came from an external server. A well-designed system prompt should tell the assistant how to treat tool results — what authority they have and what to do if a tool returns unexpected instructions.

This is relevant when MCP servers are third-party tools. A malicious or misconfigured MCP server could return content that attempts to override the system prompt's instructions. The MCP specification addresses this through the concept of trust levels: the host application (which sets the system prompt) has higher trust than tool results from a connected server. Check the MCP documentation for the current trust model and how specific clients implement it.

When to put decisions in fenbs instead of a prompt

A project decision that will change — the current preferred approach, the agreed naming convention for this sprint, the technology choice that is under review — belongs in fenbs, not a system prompt. A decision in fenbs can be updated in one place and the next session reads the current version. The same decision in a system prompt requires editing the prompt each time it changes, and there may be multiple prompts across multiple tools that all need updating.

A rule that never changes — always respond in English, never suggest changes to the authentication layer without confirmation — belongs in the system prompt where it is always present and cannot be overridden by tool results.

How to do this with fenbs

Use the system prompt for stable rules and instructions, and fenbs for decisions and context that change as the work progresses.

1. Create a free account and add a project for the work you are managing with AI assistance.
2. Write a system prompt that instructs the assistant to read current project context from fenbs at session start, using the MCP tools available.
3. Add the project decisions and current tasks to fenbs so the assistant reads live state rather than stale prompt content.
4. Connect a supported AI app to fenbs via Integrations so the tools are available in each session.
5. When a decision changes, update it in fenbs rather than editing the system prompt across multiple tools.

MCP prompts as a feature

The MCP specification includes a prompts feature: an MCP server can expose named prompts that a client can retrieve and inject into a conversation. This is a formal way to provide reusable instructions through MCP rather than through a static system prompt. fenbs uses a similar pattern: the context the assistant reads at session start is structured so that it functions like a well-written context note, not just raw data.

If you are building your own MCP server, the prompts feature is worth considering for reusable instruction sets. See mcp-tools-resources-and-prompts for a broader look at how tools, resources, and prompts fit together in the MCP model.