Support

GitHub release

Features

  • Comprehensive P4 integration: Read/write tools across files, changelists, shelves, workspaces, jobs, reviews, streams, and server information.
  • Code review workflows: P4 Code Review support for review discovery, voting, state transitions, commenting, and participant management.
  • Safety first: Read-only mode by default, ownership checks, interactive MCP elicitation (PROCEED/CANCEL) for destructive delete and obliterate operations.
  • Flexible toolsets: Configure which tool categories to enable: server, files, changelists, shelves, workspaces, jobs, reviews, and streams.
  • Robust logging: Application and session logging to the logs/ directory.
  • Optional telemetry: Consent-gated usage statistics. Disabled by default.
  • Cross platform: Supported on macOS, Linux and Windows with pre-built binaries.

Prerequisites

  • P4 Server access: Connection to a P4 Server with proper credentials
  • Authentication: Valid P4 login (ticket-based or password)

System Requirements

Component Supported Versions
Operating Systems Windows 10+macOS 12+Linux (glibc 2.34+, e.g. Ubuntu 22.04+, Rocky Linux 9+)
Perforce P4 Server 2026.1 (earlier versions untested)
Python 3.11+ (required only for building from source)

Local P4 MCP Server Installation

If you have uv installed, you can run P4 MCP Server directly without any manual installation:

# Run the server
uvx p4mcp-server

# Check version
uvx p4mcp-server --version

# Run with arguments
uvx p4mcp-server --readonly --allow-usage

This automatically fetches and runs the latest version from PyPI. No Python virtual environment setup or dependency management needed.

Requirements:

  • uv installed on your system
  • Python 3.11+ (uv will handle this automatically)

Download the appropriate binary for your operating system:

Extract and use the executable directly. No Python installation is required.

# macOS / Linux
unzip p4-mcp-server-mac.zip   # or p4-mcp-server-linux.zip
./p4-mcp-server --help
# Windows
Expand-Archive p4-mcp-server-win.zip -DestinationPath .
.\p4-mcp-server.exe --help

Requirements:

  • Python 3.11+ (with Tkinter)

Build:

  • macOS: chmod +x build.sh && ./build.sh package
  • Linux: chmod +x build.sh && ./build.sh package
  • Windows: build.bat package

Output:

  • macOS & Linux: p4-mcp-server-<version>.tgz
  • Windows: p4-mcp-server-<version>.zip

Deployment

STDIO-based deployment

Run the P4 MCP Server directly on your machine using the default STDIO transport.

Add the following to your mcp.json:

{
  "mcpServers": {
    "perforce-p4-mcp": {
      "command": "/absolute/path/to/p4-mcp-server",
      "env": {
        "P4PORT": "ssl:perforce.example.com:1666",
        "P4USER": "your_username",
        "P4CLIENT": "your_workspace"
      },
      "args": [
        "--readonly", "--allow-usage"
      ]
    }
  }
}

Note: This example shows explicit env values. If P4CONFIG is set, you can omit them and use the generic configuration example in the MCP client configuration section instead.

Run the P4 MCP Server from a Docker container with STDIO transport, allowing MCP clients to manage the container lifecycle.

Note: Docker-based execution is currently supported on macOS and Linux only.

Prerequisites

  • Docker installed and running
  • Valid P4 credentials and access to a P4 server

Pull the Docker image

docker pull ghcr.io/perforce/p4mcp-server:latest
cd /path/to/p4mcp-server
docker build -t ghcr.io/perforce/p4mcp-server .

Configure MCP Client

Add the following to your mcp.json:

{
    "servers": {
        "perforce-p4mcp-docker": {
            "command": "docker",
            "args": [
                "run", "-i", "--rm",
                "--hostname", "your-hostname",
                "-e", "P4PORT=ssl:perforce.example.com:1666",
                "-e", "P4USER=your_username",
                "-e", "P4CLIENT=your_workspace",
                "-v", "/Users/your_username/.p4tickets:/home/mcpuser/.p4tickets:ro",
                "ghcr.io/perforce/p4mcp-server:latest"
            ]
        }
    }
}

Configuration Options

Flag Description
-i Interactive mode (required for STDIO)
--rm Remove container when stopped
--hostname Match workspace host restriction
-e P4PORT P4 server address
-e P4USER P4 username
-e P4CLIENT Workspace name
-v Mount P4 tickets file

Authentication

Using P4 tickets:

# macOS/Linux
-v /Users/your_username/.p4tickets:/home/mcpuser/.p4tickets:ro

Note: Use the full path to your tickets file (not ~). After running p4 login, restart the MCP server to pick up the new ticket.

Using a password:

-e P4PASSWD="your_password"

Workspace Host Restrictions

⚠️ Important: Docker containers have their own hostname, which differs from your local machine. If your P4 workspace is restricted to a specific host, operations like sync will fail.

To resolve this, set the container hostname to match your workspace's host restriction:

--hostname your-hostname

To find your workspace host name:

# macOS/Linux
p4 client -o your_workspace | grep "^Host:"

Mounting Client Root for Write Operations

⚠️ Important: By default, the Docker container cannot access your local workspace files. For write operations like sync, submit, or reconcile, you must mount your client root directory into the container at the same path.

Add a volume mount for your client root:

-v /path/to/your/client/root:/path/to/your/client/root

Example configuration with client root mounted:

{
    "servers": {
        "perforce-p4mcp-docker": {
            "command": "docker",
            "args": [
                "run", "-i", "--rm",
                "--hostname", "your-hostname",
                "-e", "P4PORT=ssl:perforce.example.com:1666",
                "-e", "P4USER=your_username",
                "-e", "P4CLIENT=your_workspace",
                "-v", "/Users/your_username/.p4tickets:/home/mcpuser/.p4tickets",
                "-v", "/path/to/client/root:/path/to/client/root",
                "ghcr.io/perforce/p4mcp-server:latest"
            ]
        }
    }
}

To find your client root:

p4 client -o your_workspace | grep "^Root:"

Note: The mount path inside the container must match the client root path exactly, as P4 tracks files by their absolute paths.

HTTP-based deployment

Run the MCP server on a VM using the HTTP transport, allowing clients to connect over the network.

Start the server on the VM:

P4PORT=ssl:perforce.example.com:1666 P4USER=your_username P4PASSWD=YOUR_TICKET ./p4-mcp-server --readonly --transport http --port 8000

Configure the MCP client:

Add the following to your mcp.json:

{
    "servers": {
        "perforce-p4-mcp": {
            "type": "http",
            "url": "http://<ip-or-hostname>:8000/mcp"
        }
    }
}

Note: Ensure the VM's firewall allows inbound connections on the chosen port. For production use, consider placing the server behind a reverse proxy with TLS.

Run the MCP server in a Docker container using HTTP transport and expose the MCP endpoint over a host port.

Start the container:

docker run --rm -p 8000:8000 \
  -e P4PORT=ssl:perforce.example.com:1666 \
  -e P4USER=your_username \
  -e P4PASSWD=YOUR_TICKET \
  ghcr.io/perforce/p4mcp-server:latest \
  python3 -m p4mcp.main --readonly --transport http --port 8000

Configure the MCP client:

Add the following to your mcp.json:

{
  "servers": {
    "perforce-p4-mcp": {
      "type": "http",
      "url": "http://<ip-or-hostname>:8000/mcp"
    }
  }
}

Note: Docker supports HTTP-based deployment as well. The container image defaults to STDIO transport, so the HTTP startup command must explicitly override the default command. If you need write operations, also mount the client root and ticket file paths into the container.

MCP client configuration

Note: In all configuration examples below, if P4CONFIG is set, you do not need to set any environment variables in the env block. The server will use the configuration from the specified P4CONFIG file instead.

Tip: If you have uv installed, you can use uvx p4mcp-server instead of /absolute/path/to/p4-mcp-server in the command field. This eliminates the need to download or build binaries manually.

{
 "mcpServers": {
    "perforce-p4-mcp": {
       "command": "uvx",
       "args": [
          "p4mcp-server",
          "--readonly", "--allow-usage"
       ],
       "env": {
          "P4PORT": "ssl:perforce.example.com:1666",
          "P4USER": "your_username",
          "P4CLIENT": "your_workspace"
       }
    }
  }
}
{
 "mcpServers": {
    "perforce-p4-mcp": {
       "command": "/absolute/path/to/p4-mcp-server",
       "env": {
       },
       "args": [
          "--readonly", "--allow-usage"
       ]
    }
  }
}

See the JetBrains AI Assistant VCS Integration documentation for detailed configuration steps.

See the Claude Code MCP docs for more information.

Using uvx (no installation required):

{
  "mcpServers": {
    "perforce-p4-mcp": {
      "command": "uvx",
      "args": [
        "p4mcp-server",
        "--readonly", "--allow-usage"
      ],
      "env": {
        "P4PORT": "ssl:perforce.example.com:1666",
        "P4USER": "your_username",
        "P4CLIENT": "your_workspace"
      }
    }
  }
}

Using pre-built binary:

{
  "mcpServers": {
    "perforce-p4-mcp": {
      "command": "/absolute/path/to/p4-mcp-server",
      "env": {
        "P4PORT": "ssl:perforce.example.com:1666",
        "P4USER": "your_username",
        "P4CLIENT": "your_workspace"
      },
      "args": [
        "--readonly", "--allow-usage"
      ]
    }
  }
}

See the Cursor MCP documentation for more information.

{
  "mcpServers": {
    "perforce-p4-mcp": {
      "command": "/absolute/path/to/p4-mcp-server",
      "env": {
        "P4PORT": "ssl:perforce.example.com:1666",
        "P4USER": "your_username",
        "P4CLIENT": "your_workspace"
      },
      "args": [
        "--readonly", "--allow-usage"
      ]
    }
  }
}

See the Eclipse MCP documentation for more information.

{
  "servers": {
    "perforce-p4-mcp": {
      "command": "/absolute/path/to/p4-mcp-server",
      "env": {
        "P4PORT": "ssl:perforce.example.com:1666",
        "P4USER": "your_username",
        "P4CLIENT": "your_workspace"
      },
      "args": [
        "--readonly", "--allow-usage"
      ]
    }
  }
}

See the Kiro MCP documentation for more information.

{
  "mcpServers": {
    "perforce-p4-mcp": {
      "command": "/absolute/path/to/p4-mcp-server",
      "env": {
        "P4PORT": "ssl:perforce.example.com:1666",
        "P4USER": "your_username",
        "P4CLIENT": "your_workspace"
      },
      "args": [
        "--readonly", "--allow-usage"
      ]
    }
  }
}

See the VS Code documentation for more information.

{
  "servers": {
    "perforce-p4-mcp": {
      "command": "/absolute/path/to/p4-mcp-server",
      "env": {
        "P4PORT": "ssl:perforce.example.com:1666",
        "P4USER": "your_username",
        "P4CLIENT": "your_workspace"
      },
      "args": [
        "--readonly", "--allow-usage"
      ]
    }
  }
}

See the Windsurf MCP documentation for more information.

{
  "mcpServers": {
    "perforce-p4-mcp": {
      "command": "/absolute/path/to/p4-mcp-server",
      "env": {
        "P4PORT": "ssl:perforce.example.com:1666",
        "P4USER": "your_username",
        "P4CLIENT": "your_workspace"
      },
      "args": [
        "--readonly", "--allow-usage"
      ]
    }
  }
}

P4 Environment Variables

  • P4PORT - P4 Server address. Examples: ssl:perforce.example.com:1666, localhost:1666
  • P4USER - Your P4 username
  • P4CLIENT - Your current P4 workspace. Optional, but recommended

Result limit environment variables

  • P4MCP_MAX_RESULTS - Cap on the number of rows the P4 server returns per command (p4.maxresults). Default: 10000. Set to 0 to disable the limit (server default in effect). When a command would exceed this limit the server aborts it with an error rather than truncating results, so keep the value generous. Can be overridden by the --max-results CLI argument. Must be a non-negative integer; an invalid value fails fast at startup before any P4 connection is attempted.
  • P4MCP_MAX_SCAN_ROWS - Cap on the number of rows the P4 server scans per command (p4.maxscanrows). Unset by default, so admin/group policy governs scan limits. Can be overridden by the --max-scan-rows CLI argument. Must be a non-negative integer when supplied.

Logging environment variables

  • P4MCP_LOG_DIR - Directory for log files. Default: logs/ in the server executable's directory. Can be overridden by the --log-dir CLI argument.

SSL/TLS environment variables

  • P4MCP_TLS_CA_MODE - TLS certificate source mode.
    • system (default): use OS trust store via truststore. Note: In this mode, truststore overrides the verify= parameter — custom CA bundles set via P4MCP_CA_BUNDLE or --ca-bundle are ignored. To use a custom CA bundle, set P4MCP_TLS_CA_MODE=certifi.
    • certifi: disable truststore injection and use default Python TLS certificate behavior. Custom CA bundles (P4MCP_CA_BUNDLE / --ca-bundle) take effect only in this mode.
  • P4MCP_SSL_VERIFY - Set to false to disable SSL verification for P4 Code Review API requests. Default: true. Works in both TLS modes.
  • P4MCP_CA_BUNDLE - Path to a custom CA certificate bundle (PEM) for P4 Code Review API requests. Takes priority over P4MCP_SSL_VERIFY. Requires P4MCP_TLS_CA_MODE=certifi to take effect.

Telemetry environment variables

  • OTEL_EXPORTER_OTLP_ENDPOINT - OTLP collector endpoint for telemetry export. Default: https://grpc.public.prd.shared.perforce.com.
  • OTEL_EXPORTER_OTLP_PROTOCOL - OTLP export protocol. Only grpc is supported; other values fall back to grpc with a warning.

Supported arguments

  • --readonly - Control write operations.

    • If present, uses read-only mode. Safe for exploration and testing.
    • If missing, enables write operations. Requires proper permissions on your P4 Server.
  • --allow-usage - Allow usage statistics.

    • If present, allows anonymous usage statistics collection.
    • If missing, disables all usage statistics.
  • --toolsets - Specify which tool categories to enable.

    • Available: files, changelists, shelves, workspaces, jobs, reviews, streams
    • Default: All toolsets enabled.
    • query_server is always available regardless of the --toolsets setting.
  • --search-transform - Enable search-based tool discovery to reduce token overhead.

    • regex — Expose a regex pattern-matching search tool. Best for targeted lookups.
    • bm25 — Expose a natural-language relevance-ranked search tool. Best for exploratory queries.
    • both — Expose both search tools with distinct names (regex_search_tools/regex_call_tool and semantic_search_tools/semantic_call_tool).
    • If omitted, the full tool catalog is sent to the client (default, backward-compatible).
    • When enabled, query_server is always directly visible to the client.
    • Security: Admin permission checks (CheckPermissionMiddleware) and --readonly filtering remain fully enforced. Search transforms query the real tool catalog internally, so tools blocked by middleware or excluded by read-only mode are never discoverable or callable through the search interface.
  • --max-results <N> - Cap on the number of rows the P4 server returns per command (p4.maxresults).

    • Default: 10000. Set to 0 to disable the limit (server default in effect).
    • Protects against runaway AI-driven queries exhausting local memory or overwhelming the server.
    • When a command would exceed this limit the server aborts it with an error — it does not truncate — so keep the value generous.
    • Must be a non-negative integer; an invalid value fails fast at startup before any P4 connection is attempted.

    Priority order: --max-results > P4MCP_MAX_RESULTS > default (10000).

  • --max-scan-rows <N> - Cap on the number of rows the P4 server scans per command (p4.maxscanrows).

    • Unset by default, so admin/group policy governs scan limits.
    • Must be a non-negative integer when supplied; an invalid value fails fast at startup.

    Priority order: --max-scan-rows > P4MCP_MAX_SCAN_ROWS > default (unset).

  • --ssl-no-verify - Disable SSL certificate verification for P4 Code Review API requests.

    • Useful for environments with self-signed or internal CA certificates.
    • Works in both system and certifi TLS modes.
    • These SSL options only affect HTTPS Swarm connections. If the Swarm URL is http://, they have no effect.
  • --ca-bundle <path> - Path to a custom CA certificate bundle (PEM) for P4 Code Review API requests.

    • Use this to trust an internal CA without disabling verification entirely.
    • Requires P4MCP_TLS_CA_MODE=certifi to take effect. In the default system mode, truststore uses the OS trust store and ignores this setting.
    • If both --ca-bundle and --ssl-no-verify are provided, --ca-bundle takes priority (verification is performed using the specified bundle).

    Priority order: --ca-bundle > --ssl-no-verify > P4MCP_CA_BUNDLE > P4MCP_SSL_VERIFY > default (true). CLI args take priority over environment variables.

  • --log-dir <path> - Directory for log files.

    • Specify a custom directory for log files (both application and session logs).
    • Default: logs/ in the server executable's directory.
    • Can also be set via P4MCP_LOG_DIR environment variable.
    • CLI argument takes priority over environment variable.

    Priority order: --log-dir > P4MCP_LOG_DIR > default (logs/ in the server executable's directory).

Required configurations

  • Use absolute paths for the command field in all configurations.
  • Ensure environment variables are properly set for each host.
  • Different hosts may have different argument parsing. Refer to the host's documentation.

P4 configuration

User configuration

Example setup

# Windows (PowerShell)
$env:P4PORT = "ssl:perforce.example.com:1666"
$env:P4USER = "your_username"
$env:P4CLIENT = "your_workspace"
# macOS/Linux (Bash)
export P4PORT="ssl:perforce.example.com:1666"
export P4USER="your_username"
export P4CLIENT="your_workspace"

P4USER must be a standard user. P4 MCP Server runs commands such as p4 describe and p4 changes that a service-type user is not permitted to run, so a service user will cause tools to fail at runtime. Configure P4USER with a Perforce user of type standard. See p4 user in the P4 CLI documentation.

Connection-limit options

These options bound how much work a single P4 command can do, protecting the server against runaway queries:

  • max_results — Caps how many rows the P4 server returns per command. On by default with a generous value to protect against runaway queries. Lower the value to tighten the bound. Configured via P4MCP_MAX_RESULTS or --max-results.
  • max_scan_rows — Caps how many rows the server scans per command. Unset by default (governed by admin/group policy). Configured via P4MCP_MAX_SCAN_ROWS or --max-scan-rows.

Admin configuration

Manage access through group-level and user-level server properties. P4 resolves each property to a single value using two rules, applied in order:

  1. Highest sequence number wins. The -s flag is the primary sort key. It applies across all scopes — a group property at -s5 beats a user property at -s1 or default.
  2. At the same sequence number, scope is the tiebreaker: user > group > global. Between groups at the same sequence, the alphabetically-first group name wins.

P4 does not compare values semantically. It does not know that false is more restrictive than true. The winning property's value is returned as-is and checked by the MCP server.

If no property applies, MCP remains enabled unless explicitly disabled.

Master switch (global disable)

To disable MCP for all users:

p4 property -a -n mcp.enabled -v false

To re-enable group/user-based control, delete the global property first:

p4 property -d -n mcp.enabled

To prevent access for all members of a specific group:

p4 property -a -n mcp.enabled -v false -g noaccessgroup

You can set multiple group restrictions the same way.

When a user belongs to multiple groups with conflicting settings, P4's property resolution determines which value wins.

The highest sequence number (-s) wins. At equal sequence numbers, the alphabetically-first group name wins.

Example:

p4 property -a -n mcp.enabled -v false -s1 -g noaccessgroup
p4 property -a -n mcp.enabled -v true  -s2 -g accessgroup

In this example, accessgroup wins because -s2 is higher than -s1.

To block a specific user regardless of group membership:

p4 property -a -n mcp.enabled -v false -u noaccessuser

At the same sequence number, user-level properties override group-level and global settings (P4's scope tiebreaker).

Example: Even if noaccessuser is in accessgroup (where MCP is enabled), the user property at the same sequence takes precedence and MCP is disabled.

Note: A group property at a higher -s value can override a user property at a lower sequence number. To ensure a user-level property always wins, give it a high -s value or ensure no group properties use a higher sequence.

Restrict which toolsets are available server-wide using mcp.toolsets.allowed. Only listed toolsets will be enabled; all others are blocked.

Available toolsets: server, changelists, files, jobs, reviews, shelves, workspaces, streams

Allow only changelists and files:

p4 property -a -n mcp.toolsets.allowed -v changelists,files

Remove the allowlist to restore all toolsets:

p4 property -d -n mcp.toolsets.allowed

Disable all write operations (modify tools) while keeping read operations (query tools) available:

p4 property -a -n mcp.toolsets.write -v false

Re-enable writes:

p4 property -a -n mcp.toolsets.write -v true

When write=false, all modify_* tools are blocked but all query_* tools continue to work.

Enable or disable individual toolsets for a specific group.

Disable a toolset for a specific group:

p4 property -a -n mcp.toolset.changelists.enabled -v false -g reviewers

Users in reviewers are blocked from changelists. Users in other groups (with no explicit setting) retain default access.

To restrict a toolset to only one group, disable it for every other group that should not have access:

p4 property -a -n mcp.toolset.files.enabled -v false -g reviewers
p4 property -a -n mcp.toolset.files.enabled -v false -g interns
# Only groups without an explicit "false" retain default access to files

Note: All toolsets are enabled by default. Setting enabled=true for a group is redundant unless you are explicitly overriding a previous false setting. At the same sequence number, a group property overrides a global property (P4's scope tiebreaker), so a group enabled=true can override a global enabled=false. To ensure a global setting cannot be overridden, give it a high -s value. To isolate a toolset to specific groups, disable it for the groups you want to block.

Control write access for each toolset at the group level.

Disable writes for a specific toolset per group:

p4 property -a -n mcp.toolset.workspaces.write -v false -g reviewers

This blocks modify_workspaces for the group while query_workspaces remains accessible.

Restrict a group to specific tools within a toolset using mcp.toolset.<name>.tools.

Allow only query_files (block modify_files) for developers:

p4 property -a -n mcp.toolset.files.tools -v query_files -g developers

Allow both query and modify for leads:

p4 property -a -n mcp.toolset.reviews.tools -v query_reviews,modify_reviews -g leads

Tool-specific overrides can restrict access even when writes are enabled:

p4 property -a -n mcp.toolsets.write -v true
p4 property -a -n mcp.toolset.files.tools -v query_files -g developers
# Result: modify_files is BLOCKED — tool list restricts

Note: Tool-specific overrides cannot bypass write restrictions. The server checks write permissions before evaluating tool lists. If write=false is set at any level, write tools are blocked regardless of the tool list.

When a user belongs to multiple groups with conflicting settings, P4 resolves each property to a single value. The MCP server does not perform its own multi-group logic — it uses whichever value P4 returns.

P4's resolution rules for a given property name:

  1. Highest -s (sequence number) wins. This is the primary sort key.
  2. At the same sequence number: user scope > group scope > global scope.
  3. Between groups at the same sequence: the alphabetically-first group name wins.

P4 does not compare values. It picks the winning entry by position, not by content.

Example — groups at the same sequence (default):

p4 property -a -n mcp.toolset.files.enabled -v true -g developers
p4 property -a -n mcp.toolset.files.enabled -v false -g leads
# User in both groups → resolved value is "true"
# Reason: "developers" < "leads" alphabetically, so developers wins

Swapping the values would give falsedevelopers still wins regardless of the value.

Example — only one group has a setting:

p4 property -a -n mcp.toolset.files.enabled -v false -g leads
# developers has no setting
# User in developers + leads → resolved value is "false"
# Reason: leads is the only group with a value, so it wins

Example — write access:

p4 property -a -n mcp.toolset.files.write -v false -g developers
p4 property -a -n mcp.toolset.files.write -v true -g leads
# User in both groups → resolved value is "false"
# Reason: "developers" < "leads" alphabetically, not because false is "more restrictive"

Example — tool lists (no union):

p4 property -a -n mcp.toolset.reviews.tools -v query_reviews -g developers
p4 property -a -n mcp.toolset.reviews.tools -v query_reviews,modify_reviews -g leads
# User in both groups → resolved value is "query_reviews"
# Reason: "developers" wins alphabetically. P4 returns one value, not a union.

Example — using -s to control which group wins:

p4 property -a -n mcp.enabled -v false -s1 -g noaccessgroup
p4 property -a -n mcp.enabled -v true  -s2 -g accessgroup
# accessgroup wins because -s2 > -s1 (highest sequence wins)

Tip: To get predictable results with multiple groups, always use explicit -s values rather than relying on alphabetical group name ordering.

Disable a single toolset for all users without affecting others:

p4 property -a -n mcp.toolset.reviews.enabled -v false

This blocks both query_reviews and modify_reviews for all users. Other toolsets remain unaffected.

Restrict a specific group to read-only without affecting other groups:

p4 property -a -n mcp.toolsets.write -v false -g problematic_group

Users in other groups retain full write access. If a user belongs to both the restricted group and an unrestricted group, P4's property resolution determines the outcome — typically the alphabetically-first group name wins at equal sequence numbers. Use explicit -s values for predictable results.

How properties are resolved

The MCP server checks properties in this order. Each property is resolved independently by P4 using the standard resolution rules (highest -s wins, then user > group > global at equal sequence, then alphabetically-first group name).

Check order Property MCP server behavior
1 mcp.enabled If resolved value is false, block all access
2 mcp.toolsets.write If resolved value is false and tool is a write operation, block
3 mcp.toolsets.allowed If set, only listed toolsets are available
4 mcp.toolset.<name>.enabled If resolved value is false, block the toolset
5 mcp.toolset.<name>.write If resolved value is false and tool is a write operation, block
6 mcp.toolset.<name>.tools If set, only listed tools within the toolset are available

Important notes

  • Each property is resolved to a single value by P4 before the MCP server sees it. P4 uses: highest sequence number (-s) first, then scope (user > group > global) as a tiebreaker, then alphabetical group name. The MCP server does not perform its own multi-group or multi-scope resolution.

  • mcp.enabled acts as the main switch. When its resolved value is false, all access is blocked.

  • At the same sequence number, a group or user property overrides a global property. To ensure a global false cannot be overridden, assign it a high -s value.

  • Scope hierarchy (user > group > global) only applies as a tiebreaker at equal sequence numbers. A group property at -s5 will beat a user property at default sequence or -s1.

  • When a user belongs to multiple groups, the alphabetically-first group name wins (at equal -s). The winning value is used as-is — P4 does not compare true vs false or pick the "most restrictive" value. Use explicit -s values to control which group takes priority.

  • Tool-specific overrides (mcp.toolset.<name>.tools) can further restrict access but cannot bypass write restrictions. Write checks are evaluated before tool lists.

  • Property changes take effect within 60 seconds due to server-side caching, or immediately on a new MCP server connection.

  • Only the value false (case-insensitive) disables or blocks access. Any other value (including true, 1, yes, or invalid strings) is treated as not blocking.

Available tools

Query tools (read operations)

  • Actions:
    • server_info - Get P4 version, uptime, and configuration
    • current_user - Get current user information and permissions
  • Use cases - Server diagnostics, user verification, connection testing
  • Actions:
    • list - List all workspaces (optionally filtered by user)
    • get - Get a detailed workspace specification
    • type - Check workspace type and configuration
    • status - Check workspace sync status
  • Parameters: workspace_name, user, max_results
  • Use cases: Workspace discovery, configuration review, status checking
  • Actions:
    • get - Get detailed changelist information (files, description, jobs)
    • list - List changelists with filters (status, user, workspace)
  • Parameters: changelist_id, status (pending/submitted), workspace_name, max_results
  • Use cases: Code review, history tracking, changelist analysis
  • Actions:
    • content - Get file content at a specific revision
    • history - Get file revision history and integration records
    • info - Get file basic details (type, size, permissions)
    • metadata - Get file metadata (attributes, filesize, etc.)
    • diff - Compare file versions (depot-to-depot or mixed)
    • annotations - Get file annotations with blame information
    • search - Search for files by name pattern (wildcard matching)
    • grep - Search for files by content pattern (text search)
  • Parameters: file_path, file2 (for diff), pattern (for search/grep), case_insensitive (for grep), max_results, diff2 (boolean)
  • Use cases: Code analysis, file comparison, history tracking, blame analysis, file discovery, content search
  • Actions:
    • list - List shelved changes by user or globally
    • diff - Show differences in shelved files
    • files - List files in a specific shelf
  • Parameters: changelist_id, user, max_results
  • Use cases: Code review, work-in-progress tracking, collaboration
  • Actions:
    • list_jobs - List jobs associated with a changelist
    • get_job - Get detailed job information and status
  • Parameters: changelist_id, job_id, max_results
  • Use cases: Defect tracking, requirement traceability, project management
  • Actions:
    • list - List all reviews with optional filtering
    • dashboard - Get current user's review dashboard (my reviews, needs attention)
    • get - Get detailed review information
    • transitions - Get available state transitions for a review
    • files_readby - Get files read status by users
    • files - Get files in a review (with optional version range)
    • activity - Get review activity history
    • comments - Get comments on a review
  • Parameters:
    • review_id - Review ID (required for get, transitions, files_readby, files, comments, activity)
    • review_fields - Comma-separated fields to return (e.g., "id,description,author,state")
    • comments_fields - Fields for comments (default: "id,body,user,time")
    • up_voters - List of up voters for transitions
    • from_version, to_version - Version range for files action
    • max_results - Maximum results (default: 10)
  • Use cases: Code review discovery, review status tracking, comment retrieval, review activity monitoring
  • Actions:
    • list - List streams with optional filters (path pattern, owner, type)
    • get - Get a detailed stream specification
    • children - Get child streams of a given stream
    • parent - Get the parent stream
    • graph - Get the full stream graph (parent + children)
    • integration_status - Get integration status between stream and parent (p4 istat)
    • get_workspace - Get a workspace spec bound to a stream
    • list_workspaces - List workspaces bound to a stream
    • validate_file - Validate file paths against a s