Perforce operations are ambiguous without a workspace context, and here that context is a required argument rather than state the server carries between calls. One session can therefore touch two workspaces without switching, and no call silently inherits a directory something else set. The stream and client coverage goes further than a wrapper around the common commands — create, edit by specification, switch — which is what makes branch work possible from here rather than just file work. p4_raw_command labels itself as being for debugging, and treating it that way rather than as a general route is the right instinct.
A Perforce server covering file operations, changelists, streams and client workspaces, where the workspace context is an argument rather than hidden state.
- File operations: add, open for edit, mark for deletion, revert files or an entire changelist, sync from the depot with an optional force, and diff
- Changelists created with a description, files moved between them, and a changelist submitted
- p4_status for the workspace state and pending changes, and p4_info for the Perforce configuration in a directory
- Streams: listed or filtered by pattern, one stream's detail, the workspace switched to another stream, a new stream created with a parent and type, a stream specification edited, and the hierarchy shown as a graph
- Client workspaces: listed per user, one client's detail, created with a root, view and stream, edited by specification, deleted with an optional force, and switched to
- p4_raw_command, marked in its own description as being for debugging, returning stdout and stderr from an arbitrary p4 command
- mcp_perforce_version, reporting the server's own version
A Perforce workspace and its configuration, with P4CONFIG naming the config file. Every tool takes a path, so the working directory each call applies to is explicit.
One command — npx -y @cocoon-ai/mcp-perforce