MCP Activity

MCP servers are the fastest-growing extension point in Claude Code, and the fastest-growing attack surface. Any MCP server can expose tools that read files, execute code, send data externally, or...

MCP servers are the fastest-growing extension point in Claude Code, and the fastest-growing attack surface. Any MCP server can expose tools that read files, execute code, send data externally, or modify your infrastructure. Without visibility, you have no idea what your developers' MCP tools are actually doing.

AgentKeeper gives you workstation MCP configuration, real-time hook activity monitoring, Gateway activity monitoring, and policy enforcement for MCP tool calls across your organization. Claude Code and Cowork have the most complete hook-based MCP visibility today. Claude Chat in Claude Desktop uses the standalone MCP Gateway path for server, tool, routing, and audit coverage even when workstation hooks are not installed.

MCP governance controls are owner/admin-only. Developers can view allowed evidence surfaces, but they cannot change server registry decisions, import external MCP evidence, approve Gateway event exceptions, mutate MCP policies, run policy simulations, export MCP event evidence, or manage hosted AgentKeeper MCP Server clients.

How it works

Every connected Claude Code MCP call passes through AgentKeeper's PreToolUse hook. When the tool name starts with mcp__, AgentKeeper identifies it as an MCP skill and runs additional policy checks before the tool executes. Other agent surfaces use the same policy engine when their hook payload includes an MCP-style tool name or server/tool metadata.

MCP tool naming convention

Claude Code follows a standard naming pattern for MCP tools:

mcp__<servername>__<toolmethod>

Example tool name	Server	Method
`mcp__github__create_pull_request`	github	create_pull_request
`mcp__slack__send_message`	slack	send_message
`mcp__filesystem__read_file`	filesystem	read_file
`mcp__postgres__execute_query`	postgres	execute_query

The mcp__ prefix is how AgentKeeper distinguishes MCP skills from built-in Claude Code tools like Bash, Read, and Write.

Detection flow

Claude Code fires the PreToolUse hook with the tool name and input
AgentKeeper parses the mcp__ prefix to extract the server name and tool method
Policy checks run against the parsed skill: blocked list, allowed list, and warn-only list
The tool is either denied (with an explanation), warned (logged but allowed), or passed through
Every MCP tool call is recorded in the audit trail regardless of verdict

Policy types

Configure MCP skill policies in the dashboard under Team → Policies → MCP Access. Three policy types give you progressive control, from passive monitoring to full lockdown.

Blocked skills

Deny specific MCP skills outright. When a blocked skill is invoked, Claude Code receives a deny response and the tool does not execute.

blocked_skills: ["mcp__slack", "mcp__github__delete_repo"]

Matching supports two levels of granularity:

Pattern	What it blocks
`mcp__slack`	All tools from the Slack MCP server
`mcp__github__delete_repo`	Only the `delete_repo` tool from GitHub
`slack`	Shorthand, equivalent to `mcp__slack`

Use server-level blocks to cut off an entire MCP server. Use tool-level blocks for surgical restrictions.

Allowed skills only

When set, only the listed skills are permitted. Everything else is denied. This is allowlist mode, the most restrictive option.

allowed_skills_only: ["mcp__github", "mcp__linear__create_issue"]

In this example, all GitHub MCP tools are allowed, plus the specific create_issue tool from Linear. Any other MCP tool call is denied with a clear explanation.

Allowlist mode is ideal for locked-down environments where you want to explicitly approve every MCP integration your team can use.

Warn-only skills

Flag specific skills in the audit trail without blocking them. The tool call proceeds normally, but the event is recorded with a warning badge in the Security dashboard.

warn_only_skills: ["mcp__filesystem", "mcp__postgres"]

Warn-only mode is the right starting point when you are rolling out MCP governance. Monitor what your team uses before deciding what to block.

Policy evaluation order

When a tool call arrives, AgentKeeper evaluates MCP skill policies in this order:

Blocked tools (org-level), checked first, applies to all tools including MCP
Blocked skills: MCP-specific blocklist
Allowed skills only: if non-empty, deny anything not on the list
Warn-only skills: if the detection engine flags the tool, downgrade block to warn
Detection engine: standard threat detection patterns run on the tool input

A tool blocked at any step does not proceed to the next. The first deny wins.

Group-based overrides

When an Identity Provider is connected (Entra ID, Google Workspace, or Okta), MCP skill policies can be overridden per directory group. Group profiles layer on top of Base Policy, most restrictive wins.

Scenario	Org policy	Group override	Effective policy
Engineering gets full access	Block `mcp__slack`	Engineering: no override	`mcp__slack` blocked
Contractors restricted	Allow all	Contractors: block `mcp__github__delete_repo`	`delete_repo` blocked for contractors only
Sales locked to CRM	Allow all	Sales: allowed only `mcp__salesforce`	Sales can only use Salesforce MCP tools

When a user belongs to multiple groups, overrides are merged and the most restrictive combination applies. Blocked skills from any group are always blocked. Allowed-only lists are unioned across groups.

Group-based overrides require a Team plan. See Identity Providers for setup instructions.

MCP Activity and Inventory

AgentKeeper provides two complementary views of MCP server activity, each answering a different question.

Workstation MCP configuration (Agent Inventory)

The Workstation MCP configuration section on the Agents page shows every MCP server configured across your workstation fleet, discovered at session start before any tool is called.

The scanner reads mcpServers from three locations on each workstation:

File	Source label
`~/.claude/settings.json`	`global`
`.claude/settings.json` (project)	`project`
`.mcp.json` (project)	`project`

For each server found it records:

Server name: the key in mcpServers (e.g., postgres, filesystem)
Type: transport: stdio, http, or sse
Command: the binary basename (e.g., npx, python3), args and env vars are never captured
Source: global or project
Host count and timestamps

Use this view to answer: what MCP servers are configured on our workstations, even on machines where no tools have been invoked yet?

Observed hook activity (Security dashboard)

The MCP Activity section on the Security dashboard shows every MCP tool that has actually been called, aggregated from shield events.

Skills are grouped by server name. Each tool displays:

Invocation count: how many times the tool has been called
Policy status: allowed, blocked, or warned
Last seen: when the tool was last invoked
Hostnames: which workstations are using it

Use this view to answer: what tools are developers actually invoking through connected hooks, and how often?

Routed Gateway activity (MCP Gateway)

The MCP Gateway area shows Gateway-managed servers, tools, clients, decisions, and drift. Gateway-only deployments do not need workstation hooks or Agent Inventory scans. They provide routing and policy evidence for MCP traffic, but workstation or person attribution only appears when the Gateway receives real hostname, user, SSO, or MDM evidence.

Use this view to answer: what MCP traffic is routed through the gateway, what was blocked or warned, and which servers or tools changed?

Owner/Admin controls in the Gateway area include server registry updates, external evidence import, event exception approval, policy mutation, policy simulation, and event export. Event exports remain sealed and do not include raw prompt content.

All three views build automatically when their reporting paths are installed. Start with Agent Inventory to understand workstation configuration, use MCP Activity to understand hook-observed usage, and use MCP Gateway for standalone routed MCP control.

Audit trail

Every MCP tool call is logged with full context:

Field	Description
`mcp_server`	The MCP server name (e.g., `github`)
`mcp_tool`	The specific tool method (e.g., `create_pull_request`)
`verdict`	`passed`, `warned`, or `blocked`
`timestamp`	When the tool call occurred
`hostname`	Which workstation made the call
`session_id`	The Claude Code session that triggered it

Audit events are searchable in the Activity page. Filter by MCP server name, tool method, verdict, or hostname to investigate specific activity.

Why MCP skills need governance

MCP servers run with the same permissions as Claude Code itself. A single malicious or misconfigured MCP server can:

Read sensitive files: SSH keys, .env files, credentials, source code
Execute arbitrary commands: shell access through tool wrappers
Exfiltrate data: send code, secrets, or proprietary data to external endpoints
Modify infrastructure: create repos, delete resources, push code, send messages
Bypass security controls: MCP tools are not covered by Claude Code's built-in permission model

Without monitoring, your security team has zero visibility into what MCP tools developers install, what those tools access, and whether they comply with your organization's security policies.

AgentKeeper closes this gap with a clear progression:

Inventory: discover what MCP servers your team has configured
Monitor: flag sensitive MCP activity in Runtime Shield and the activity feed (all plans)
Enforce: block dangerous tools or restrict to an approved allowlist (Team plan)
Segment: apply different policies per team via group overrides (Team plan)

Plan availability

Feature	Free	Pro	Team
MCP skill detection and audit trail	Yes	Yes	Yes
Blocked skills policy	No	No	Yes
Allowed skills only (allowlist)	No	No	Yes
Warn-only skills	No	No	Yes
MCP Activity dashboard (observed calls)	Yes	Yes	Yes
Proactive MCP server discovery	No	Yes	Yes
Group-based policy overrides	No	No	Yes

MCP skill monitoring is available on all plans. Skill policy enforcement and group-based overrides require a Team plan with an Identity Provider connected.

Configuration examples

Monitor everything, block nothing

Start here. Enable log_all_tool_calls in your Claude Code policies and let MCP Activity populate for a week.

{
  "blocked_skills": [],
  "allowed_skills_only": [],
  "warn_only_skills": ["mcp__filesystem", "mcp__postgres"],
  "log_all_tool_calls": true
}

Block risky servers, allow the rest

After reviewing your inventory and MCP Activity, block servers that access infrastructure or send external data.

{
  "blocked_skills": [
    "mcp__slack",
    "mcp__email",
    "mcp__filesystem__write_file"
  ],
  "allowed_skills_only": [],
  "warn_only_skills": []
}

Allowlist mode for high-security environments

Only permit the MCP tools your team explicitly needs. Everything else is denied.

{
  "allowed_skills_only": [
    "mcp__github",
    "mcp__linear",
    "mcp__postgres__execute_query"
  ],
  "blocked_skills": [],
  "warn_only_skills": []
}

FAQ

Does MCP skill monitoring add latency to tool calls? No. Policy checks are pure string matching against cached policy data. They add under 1ms to the hook evaluation.

What happens if a tool is in both the blocklist and the allowlist? The blocklist is evaluated first. A blocked skill is always denied, even if it appears in the allowed list.

Can I use wildcards in skill patterns? Patterns support server-level prefix matching (e.g., mcp__github matches all GitHub tools) and exact tool matching. Glob-style wildcards are not currently supported.

Do built-in Claude Code tools (Bash, Read, Write) go through MCP skill checks? No. Built-in tools are handled by the standard policy checks (blocked tools, blocked commands, blocked write paths). MCP skill policies only apply to tools with the mcp__ prefix.

How do I see which MCP servers my team has installed? Use Workstation MCP configuration on the Agents page for proactively discovered workstation settings. Use MCP Gateway for Gateway-managed servers and tools. The Security dashboard shows hook-observed tool-level activity from actual invocations. See Agent Inventory for details on how the scanner works.

Was this page helpful?