{"id":34804,"date":"2026-09-18T05:00:00","date_gmt":"2026-09-18T03:00:00","guid":{"rendered":"https:\/\/sii.pl\/blog\/?p=34804"},"modified":"2026-09-17T13:54:14","modified_gmt":"2026-09-17T11:54:14","slug":"cursor-under-the-hood-mcp-skills-rules-and-plugins","status":"publish","type":"post","link":"https:\/\/sii.pl\/blog\/en\/cursor-under-the-hood-mcp-skills-rules-and-plugins\/","title":{"rendered":"Cursor under the hood: MCP, Skills, Rules, and Plugins"},"content":{"rendered":"\n

Most people who hear about Cursor for the first time picture a “code editor with an AI chat on the side“.<\/del>.”<\/ins> That is a bit like calling an airplane a “car that flies”. Technically true, but it misses the point.<\/p>\n\n\n\n

Cursor does not just suggest the next line of code. It can read your whole project, open a terminal, run tests, fix a bug, pull a design from Figma, check a ticket in your task tracker, and open a Pull Request at the end. That whole “nervous system” sits on a few mechanisms most people have never heard of: MCP, Rules, Commands, Skills,<\/ins> and plugins. <\/ins><\/p>\n\n\n\n

This article breaks them down without the fluff.<\/del><\/p>\n\n\n\n

\"The\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
Fig. 1 The Cursor AI Ecosystem<\/figcaption><\/figure>\n\n\n\n

How it actually works under the hood<\/strong><\/strong><\/h2>\n\n\n\n

A regular AI chat works like a conversation through a window: you paste a code snippet, you get an answer, and it’s done. It does not see your project, it does not know your folder structure, and it has no idea you already have a function for the same thing.<\/p>\n\n\n\n

Cursor works differently, because it has two things a plain chat does not.<\/p>\n\n\n\n

    \n
  1. The first is code indexing<\/strong>. Cursor builds embeddings, mathematical “fingerprints” of every file in the project, so during a conversation, it can find the right file on its own instead of waiting for you to point at it. Your code stays on your disk. Only those vectors go to the cloud.<\/li>\n\n\n\n
  2. The second is the agent loop<\/strong>. Instead of one answer, you get a cycle: the agent reads a file, edits code, runs a terminal command, checks the result, and if something failed, it tries again. On its own. Without you clicking “paste that again.”<\/li>\n<\/ol>\n\n\n\n

    Note:<\/strong> this autonomy does not mean the agent does whatever it wants without asking. By default, it always asks for approval before running terminal commands. You can loosen that, but do it carefully.<\/p>\n\n\n\n

    That loop is exactly why MCP, Rules, Commands, and Skills matter at all. If the agent could not work through multi-step tasks on its own, the whole ecosystem would be useless.<\/p>\n\n\n\n

    MCP, or when the agent leaves your codebase<\/strong><\/strong><\/h2>\n\n\n\n

    MCP (Model Context Protocol)<\/strong> is an open standard that lets the agent talk to tools outside your project: task systems, databases, Figma, GitHub, a browser, and many more. Without it, the agent only sees what sits in the project folder and what you type into the chat. With MCP, it can go out and check something externally on its own.<\/p>\n\n\n\n

    The simplest analogy: MCP is like a USB socket for an AI agent<\/strong>. You do not need to invent a new cable for every device. You share one standard and plug in almost any “adapter”.<\/p>\n\n\n\n

    The mechanics are simple. Cursor acts as the client, and each MCP server (a separate, isolated process) unlocks a specific service. You configure it in one file:<\/p>\n\n\n

    \n\/\/ .cursor\/mcp.json\n{\n  "mcpServers": {\n    "github": {\n      "command": "npx",\n      "args": ["-y", "@modelcontextprotocol\/server-github"],\n      "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}" }\n    },\n    "figma": {\n      "url": "https:\/\/mcp.figma.com\/mcp"\n    }\n  }\n}\n<\/pre><\/div>\n\n\n
    Then you just write what you want in plain language:<\/p>\n\n\n
    \nFetch GitHub issue #42, implement the fix, write tests, and open a Pull Request.\n<\/pre><\/div>\n\n\n
    In one flow, the agent reads the issue, analyzes the code, applies changes, adds tests, commits, pushes, and finally returns a link to the finished PR. No jumping between five apps.<\/p>\n\n\n\n
    The same pattern works with Figma (the agent pulls layout, colors, and spacing, then generates a component), with a database (the agent reads a table schema and writes a migration), or with test tools that can self-heal after a failed run.<\/p>\n\n\n\n
    Pro tip:<\/strong> only keep the MCP servers you actually use every day connected at the same time, two or three at most. Think GitHub for code, Figma for design, Jira for tickets. Everything else just sits there, making it harder for the agent to pick the right tool, so switch it on only when you actually need it.<\/p>\n\n\n\n
    Security note:<\/strong> keep tokens and API keys in environment variables. Never hardcode them in the config file. That file often ends up in the repository, and then everyone on the team can see your private token.<\/p>\n\n\n\n
    \"Uproszczony\n\t\t\t\n\t\t\t\t\n\t\t\t<\/svg>\n\t\t<\/button>
    Fig. 2 Simplified task workflow using an external tool<\/figcaption><\/figure>\n\n\n\n
    Rules, Commands, and Skills: the agent’s brain and hands<\/strong><\/strong><\/h2>\n\n\n\n
    This is where it gets interesting, because people mix these three up most often. The difference is simple if you put it into one sentence.<\/p>\n\n\n\n