Cursor Rules for MCP: Give Tool Use a Clear Purpose

Cursor rules for MCP tell the AI assistant what to do when it has access to outside tools through MCP (Model Context Protocol, a standard way for AI apps to use outside services). The rules cover three questions: which tools to discover and read at session start, what the assistant must do before using a tool, and how to report what it did with a tool so the next session knows what changed.

For projects that use fenbs over MCP, these rules turn the connection into a consistent habit: read the project context first, record progress before stopping, and surface any tool-driven changes in the task history. Without them, an assistant will use available tools whenever it seems useful, without a clear pattern the team can review or trust.

What MCP rules should cover

• Session start: which MCP tools to list and which context to read before starting any work.
• Permission to act: which MCP operations may proceed automatically and which need a person to confirm.
• Reporting: what the assistant should record after a tool-driven action so the change is visible.
• Error handling: what to do if a tool call fails or returns an unexpected result.
• Data boundaries: what information from project management tools the assistant may use and what it must not write to a task.
• Scope limits: which MCP servers are connected and what each one is for.

A starting template

# MCP tool use rules

## At session start
- List connected MCP tools before starting work.
- If fenbs is connected: read the project context (Rules, Where we left off,
  In progress tasks) before doing anything else.
- If a project management tool (Jira, Linear, ClickUp) is connected: read
  the relevant task before starting work on it.

## Before using any MCP tool
- State what you are about to do and why.
- If the action creates, updates, or deletes data in an outside system, ask
  first unless the task explicitly authorizes it.

## After using a tool
- Report what the tool did: what it read, what it changed, and what the
  result was.
- If the tool updated a task or added a comment, note the reference.

## Error handling
- If a tool call fails, report the error before trying an alternative.
- Do not silently skip a tool call that was part of the plan.

## Data limits
- Do not write personal data, credentials, or code into a task description
  or comment.
- Do not summarize a private conversation into a public task.

Connecting to project management tools

Cursor supports MCP connections to project management tools like Jira, Linear, ClickUp, Asana, and Trello. Each connection lets an assistant read and update tasks in that tool. Rules about which operations are automatic and which need a person to confirm are especially important here, because changes to a shared task board are visible to the whole team.

The ClickUp MCP Cursor, Jira MCP Cursor, Linear MCP Cursor, Asana MCP Cursor, and Trello MCP Cursor guides each cover the setup steps for their respective tools.

Fenbs as the shared record for MCP work

When Cursor is connected to fenbs over MCP, the session start rule above gives a consistent structure: read the rules and context before acting, then save progress before stopping. This turns each session into a predictable unit that the next person or assistant can resume from a known state.

The Decisions and rules in fenbs also serve as instructions the assistant reads first, before the .cursorrules file. If a Decision says "do not create new tasks without asking," that instruction reaches the assistant through the MCP context, not just the rules file. The two work together rather than duplicating each other.

How to set up MCP rules with fenbs

1. Create a free account and add your project to fenbs. Write any standing rules about MCP tool use as Decisions: which tools are authorized, what needs approval, how to report changes.
2. Add the template above to your project's .cursor/rules/ directory. Update the template to name the actual MCP servers connected to your Cursor setup.
3. Connect Cursor to fenbs from Integrations. The assistant will read the Decisions and Where we left off before starting, giving each session a consistent starting point.
4. Review what the assistant reports after tool-driven actions. If a report is incomplete, update the rules to be more specific about what to include.

Read-only versus read-write tool permissions

Not all MCP tools carry the same risk. A tool that reads task titles from a project board is much lower risk than one that creates, moves, or closes tasks. Write separate rules for each category. Read operations can often proceed automatically without prompting; write operations on shared systems should require explicit confirmation before the assistant acts.

Some MCP servers expose both read and write tools through a single connection. If your rules allow reading from a tool but not writing, name the specific tools in each category. An assistant with a clear list of approved read operations and restricted write operations will ask before crossing the boundary rather than inferring it from context.

Multiple MCP servers in the same session

Cursor supports multiple MCP servers connected at the same time. When a session has both fenbs and a project management tool like Linear or Jira connected, the rules need to say which one to use for which purpose. Without that, an assistant may record progress in both, or read context from one and write to the other.

A rule as simple as "fenbs is for project context and decisions; Jira is for ticket status only" gives the assistant a clear division. If the two tools overlap — both can store task comments, for example — the rule should say which one is the record of truth for each type of information.

What to watch for

The most common MCP rule failure is rules that are too vague. "Ask before making changes" is useful but incomplete. "Ask before creating, updating, or deleting a task in any connected project management tool" is specific enough to act on. Write rules at the level of specific operations, not general caution.

MCP tools that read data are lower risk than tools that write. Write the rules accordingly: read operations can often proceed automatically; write operations, especially to shared systems, should require confirmation. Review the connected tools periodically and remove any that are no longer needed.