Ask HN: In Cursor/agents, do plugins hide MCP tools from the main agent?

4 points by azebazenestor 4mo ago ↗ HN

Quick architecture question.

When using MCP servers directly in Cursor, the agent seems to see all tools at the same level.

But when using a plugin/extension that internally connects to MCP servers, does the main agent:

see only the plugin as a single tool and delegate to a sub-agent inside it, or

still see every underlying MCP tool individually?

In other words: do plugins act as a tool abstraction boundary, or just a packaging/install mechanism?

5 comments

[ 2.7 ms ] story [ 21.7 ms ] thread

beratbozkurt0 4mo ago ↗

I've recently started using Codex and installed Figma MCP. The outputs were really good. I achieved a 90% success rate, and I fixed the rest myself.

[dead] allinonetools_ 4mo ago ↗

[flagged]

[dead] hifathom 4mo ago ↗

[flagged]

Dollarland 4mo ago ↗

From my experience building Dollarland (dollar-land.vercel.app) with a LangChain/OpenAI backend, it usually depends on how the tool-calling schema is defined in the manifest.

In most current implementations, plugins act as an abstraction boundary. The main agent usually sees the 'Plugin' as a single tool (a 'super-tool') and delegates the specific MCP calls to a sub-agent or a controller within that plugin.

If you expose every underlying MCP tool individually to the main agent, you run into 'Context Window Bloat' where the agent gets confused by too many options. Keeping them 'hidden' behind the plugin interface is actually better for agentic stability in a production environment.

lyaocean 4mo ago ↗

Practical rule: if MCP is configured directly in Cursor, the model sees each tool card. If a plugin wraps MCP behind its own API, the model usually sees only the plugin surface.

Easiest way to verify in your setup: ask the agent to list callable tools, then compare direct-MCP mode vs plugin mode on the same workspace. The delta tells you exactly where the abstraction boundary is.