Support Tool Allowlists / Tool Profiles in codebase-memory-mcp

[ZaituDev]

What problem does this solve?

---

Currently, codebase-memory-mcp advertises its complete tool surface to every MCP client.

As the number of available tools grows, many users only need a subset of the functionality exposed by the server.

Common examples include:

• Reducing cognitive load for LLMs by exposing only relevant tools
• Creating specialized assistants focused on architecture exploration
• Creating assistants focused on code search and navigation
• Limiting available capabilities for particular workflows
• Reducing tool-selection errors when many tools have overlapping purposes
• Creating simpler and more focused MCP environments

Today, users must either:

• Expose all tools
• Rely on client-side filtering
• Create MCP proxy servers
• Maintain custom forks

All of these solutions move tool-selection concerns outside the server itself.

As codebase-memory-mcp continues to grow, this becomes increasingly difficult to manage.

---

Proposed solution

Allow users to specify which tools should be advertised by the MCP server.

Example:

{
  "mcpServers": {
    "codebase-memory-mcp": {
      "command": "codebase-memory-mcp",
      "enabled_tools": [
        "search_graph",
        "get_architecture",
        "trace_path",
        "search_code"
      ]
    }
  }
}

Alternatively, support named profiles:

{
  "mcpServers": {
    "codebase-memory-mcp": {
      "command": "codebase-memory-mcp",
      "profile": "architecture"
    }
  }
}

with profiles defined separately.

The server would only advertise the selected tools during MCP capability negotiation.

Benefits:

• Smaller and cleaner tool surfaces
• Reduced LLM tool-selection complexity
• Easier workflow specialization
• Better multi-agent support
• No need for proxy servers
• No need for custom forks
• Future tools remain opt-in rather than automatically appearing everywhere

---

Alternatives considered

Client-side filtering

Many MCP clients support filtering or tool allowlists.

However, filtering behavior varies by client and is not enforced at the server level.

MCP proxy servers

A proxy can selectively re-expose tools, but introduces additional infrastructure and maintenance burden.

Forking codebase-memory-mcp

Provides complete control but increases maintenance costs and makes upgrades more difficult.

Exposing all tools

Works for small tool sets, but becomes harder to manage as the number of tools grows and workflows become more specialized.

---

Confirmations

• I searched existing issues and this is not a duplicate.

[github-actions]

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

• the codebase-memory-mcp --version you're on
• the exact steps or command you ran
• a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.

[DeusData]

Thanks for the proposal. Current main already supports two server-enforced restricted profiles:

• --tool-profile=scout exposes seven fast discovery and coverage tools.
• --tool-profile=analysis exposes eleven read-only analysis tools.

Both profiles filter tools/list, reject direct calls to tools outside the profile, and disable the HTTP/UI surface. In an MCP client configuration the interoperable form is:

{"command":"codebase-memory-mcp","args":["--tool-profile=scout"]}

Arbitrary fields such as enabled_tools or profile in the client configuration are not passed to the MCP server process, so they cannot be enforced by the server without client-specific behavior.

The part not currently implemented is an arbitrary user-defined allowlist or custom named profile. Before adding that permanent CLI/configuration surface, please describe the concrete tool set that neither scout nor analysis covers and the client or multi-agent workflow that requires it. That will let us evaluate the smallest stable extension, including fail-closed behavior for typos and future tools. Marking awaiting-reporter for that concrete gap; the request remains assigned to 0.9.2-rc.