Cursor Subagent MCP Toolset Control Request

Ideas Feature Requests
, , ,
1

Feature request for product/service

Cursor IDE

Describe the request

Currently, all custom subagents (.cursor/agents/*.md) automatically inherit every configured MCP server and every tool within those servers from the parent environment. There is no way to “un-inherit” or scope this.

I am requesting a configuration schema within the subagent frontmatter that allows for granular control over the agent’s toolset.

Problems

  • Forced Inheritance: Subagents are “polluted” with dozens of irrelevant tools, wasting context tokens and increasing the risk of model confusion.
  • Lack of Permission Control: A subagent designed for “Read Only” tasks still inherits destructive tools (e.g., delete_table or rm_dir) if the parent MCP server provides them.
  • Token Inefficiency: Large JSON schemas for unused tools are sent in every API call, significantly increasing costs.

Proposed Solution

Allow a mcp_config block in the subagent YAML that supports both server-level and tool-level whitelisting.

Example Syntax

---
name: specialized-subagent
mcp_servers:
  - name: "database-server"
    tools: ["read_query", "list_tables"] # Only these specific tools
  - name: "filesystem"
    tools: ["read_file"] # Exclude write/delete tools
---

Expected Benefits

This ensures the subagent only “sees” the specific tools required for its role, leading to:

  • Better Security: Prevents accidental or malicious use of destructive tools in read-only subagents
  • Lower Costs: Reduces token consumption by excluding irrelevant tool schemas from API calls
  • Higher Accuracy: Reduces model confusion by eliminating irrelevant options from the tool context window
4

Hey, thanks for the detailed feature request and the syntax example. That’s really helpful.

Confirming the current behavior: custom subagents inherit all MCP tools from the parent, and the only way to restrict it is the readonly flag, which blocks MCP entirely with no per-tool control. Per-server or per-tool whitelisting via frontmatter isn’t supported right now.

We’re aware of the gap, and we’re discussing the spec internally, but I can’t share a concrete timeline or the final config format yet. I’ll pass along your example with an mcp_servers block and a tool-level array as a clear signal. The use case is easy to see and helps with prioritization, especially for token efficiency and read-only safety.

A couple related threads if you want to follow along:

If there’s an update on the design, I’ll post it here.