Perforce P4 MCP Server

Official

by perforce

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2026.3.2996147
Disambiguation5/5
Every tool targets a distinct resource and action, with clear separation between query_ (read) and modify_ (write) operations. There is no overlap or ambiguity between tools.
Naming Consistency5/5
Tools follow a consistent 'verb_resource' pattern: 'query_' for reads and 'modify_' for writes, applied across all resource types. This pattern is predictable and intuitive.
Tool Count5/5
With 15 tools, the server is well-scoped for a version control system. Each tool covers a distinct operation area (streams, workspaces, files, changelists, shelves, jobs, reviews, server info), without excess or deficiency.
Completeness4/5
The tool set provides comprehensive CRUD-like operations for core Perforce resources. Minor gaps exist (e.g., no admin or label operations), but the essential workflows for typical usage are well-covered.
Average 3.3/5 across 15 of 15 tools scored. Lowest: 2.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 13 of 14 community issues answered or closed in the last 6 months
- 13 commits in the last 12 weeks
- Last stable release on June 30, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only mentions 'WRITE permission' and does not disclose side effects, error conditions, idempotency, or behavior for actions like 'obliterate' (which requires approval), leaving agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but at the expense of completeness. For a tool with 30 parameters and 22 actions, this is under-specification rather than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema, the description lacks context on how to choose among the many actions, required permissions beyond WRITE, and behavioral details. The tool is complex, and the description is too brief to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the schema already documents parameters. The description adds no value for parameter semantics; it does not summarize key parameters or guide selection among the many parameters. Baseline 3 would be too generous given the complexity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create/update/delete reviews (WRITE permission)', clearly indicating the verb and resource. However, it does not convey the full range of 22 different actions available (e.g., vote, transition, comment), making it slightly vague for the tool's actual scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings like `modify_changelists` or `modify_jobs`. It mentions WRITE permission but lacks context on specific scenarios or prerequisites for individual actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions 'WRITE permission' but does not disclose side effects, destructive potential, or other behavioral traits. For a tool with many mutating actions (delete, force, reverse, etc.), this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that lists actions with commas. It is relatively concise but could be better structured (e.g., bullet points) to improve readability. No wasted words, but the list approach feels rushed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (34 parameters, 14 action types, output schema present), the description is too sparse. It does not explain return values, prerequisites for actions, or common usage patterns. The agent needs more context to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already describes each parameter. The description adds minimal value beyond grouping actions; it does not clarify parameter interactions or provide usage examples. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description lists specific actions (create, update, delete, edit_spec, etc.) and resources (streams, workspace), making it clear what the tool does. It distinguishes from sibling query tools like query_streams by implying mutation. However, the list format is somewhat cluttered, and the phrase '(WRITE permission)' at the end adds context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., modify_workspaces for workspace creation). No when-not-to-use or prerequisite info. The description assumes the agent knows which action to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description informs that the tool requires WRITE permission and performs linking/unlinking, but it does not disclose behavioral details such as what happens to existing associations, whether the operation is reversible, or any side effects. The schema's action enum descriptions provide minimal clarity, but the description itself is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous information. Every word contributes to stating the tool's purpose and permissions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and fully described parameters, the description is too sparse. It omits any mention of return values, prerequisites, or behavioral context that would help an agent understand the tool's full operation. The tool's mutation nature and lack of annotations increase the need for more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with verbose parameter descriptions that fully explain each parameter's role. The tool description adds no additional meaning beyond what the schema already provides, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool links or unlinks jobs, specifying the resource (jobs) and action. It distinguishes from siblings like query_jobs (read) by implying write operations, although it does not explicitly differentiate from other modify tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a permission hint (WRITE permission) but provides no guidance on when to use this tool versus alternatives like modify_changelists, which might also handle job associations. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the burden of disclosing behavior. It mentions 'READ permission' but fails to state what happens if the file does not exist, whether the tool is destructive, rate limits, or other side effects. The listed actions imply read-only, but no further traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs multiple actions and permissions. While concise, it lacks structure (e.g., bullet points) and front-loads the most important information. It is not overly verbose, but could be better organized for quick scanning by an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 8 actions, enums) and the presence of an output schema, the description should provide richer context like action-specific behavior, error handling, or examples. It does not explain how to choose among actions or how parameters interact (e.g., file2 for diff). This leaves gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds minimal value beyond the schema: it lists actions and notes permissions, but does not clarify parameter relationships or usage nuances that the schema already covers. For instance, the schema already describes max_results bounding and file_path examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves file content, history, info, diff, annotations, and performs search by name and grep by content. It lists distinct actions under a single verb 'Get', making the purpose specific. Sibling tools like modify_files or query_streams have different resources or operations, so this tool is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives (e.g., query_files vs query_changelists) or among its own actions. There are no explicit when-to-use or when-not-to-use instructions, and no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavioral traits. It only states 'READ permission', implying read-only, but lacks details on side effects, rate limits, output format, or the fact that different actions require different parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists all actions, but it lacks structure (e.g., bullet points or grouping) for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (21 parameters, 12 actions, output schema exists), the description is far too sparse. It does not clarify which parameters apply to which action, nor does it mention the return format or that the tool supports multiple disparate operations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add any parameter-specific information; it only lists actions, which is already implied by the enum parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly enumerates all supported actions (list, get spec, children/parent/graph, integration status, workspaces, validate files, check resolve, interchanges) and indicates READ permission, clearly distinguishing it from sibling write tools like modify_streams.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., query_workspaces or query_files). There is no mention of prerequisites, exclusions, or context for specific actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'WRITE permission' but does not explain side effects, destructive potential, or what happens during actions like revert or reconcile. The schema reveals modes and force flags, but the description omits behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence listing actions and permission, which is concise and has no wasted words. However, it lacks structure such as separating actions or providing additional context. It is efficient but could be more organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 actions, 7 parameters, and an output schema, the description is very incomplete. It does not explain the differences between actions, when to use each mode, or what the return value looks like. The output schema is present but unused in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional semantic context beyond the schema's parameter descriptions. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly lists all supported file modification actions (add, edit, move, delete, revert, reconcile, resolve, sync) and specifies 'WRITE permission', clearly indicating it is a write operation for files. This distinguishes it from sibling tools like query_files (read-only) and other modify tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists the actions but does not provide explicit guidance on when to use this tool versus alternatives like modify_changelists or query_files. It implies file modification contexts but lacks when-not instructions or differential advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It mentions 'READ permission' indicating non-destructiveness but lacks details on side effects, rate limits, or error behavior. Minimal transparency beyond the read-only hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundancy. However, it is very terse for a tool with 4 parameters and multiple actions; more structured front-loading of key information (e.g., required parameter usage) would improve usability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, 4 action enums) and the presence of an output schema, the description fails to explain pagination, error scenarios, or prerequisites beyond 'READ permission'. It leaves gaps despite the schema covering parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats the action descriptions already in the schema (e.g., 'list returns all workspaces matching filters') without adding new meaning or clarifying parameter interactions beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'get', 'list', 'check' actions on workspaces, and explicitly mentions 'READ permission', distinguishing it from sibling tools like 'modify_workspaces'. It covers all four actions in the input schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a read-only use case via 'READ permission' but does not explicitly state when to use this tool versus alternatives like query_streams or modify_workspaces. No when-not-to-use or conditional guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions 'WRITE permission' but does not disclose destructive nature of delete, whether updates are partial or full, or side effects of switching workspaces. Critical behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main actions. It is clear and waste-free, though could benefit from a list format for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description adequately covers the tool's purpose and permission. However, it lacks context on prerequisites, consequences of each action, and when to use specific actions, leaving gaps for a multi-action tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already documents all parameters. The description adds only a summary of actions and permission hint, not providing additional semantic context beyond what the schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs create, delete, update, and switch actions on workspaces, which are distinct from sibling tools like query_workspaces (read-only) and modify_streams (different resource). The mention of 'WRITE permission' further clarifies the action type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for modifying workspaces but offers no explicit guidance on when to use this tool over siblings (e.g., query_workspaces for reading) or which action to select. No usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks disclosure of behavioral traits beyond READ permission. Does not mention idempotency, safety, side effects, or output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. But could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and existing output schema, description is minimal but functional. Lacks details on action differentiation or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 7 parameters (100% coverage). Description adds no additional meaning beyond schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets changelist details and lists changelists. (READ permission) distinguishes it from modify tools. Specific verb+resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates read-only usage via '(READ permission)', but does not explicitly state when not to use or mention alternative tools like modify_changelists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states 'READ permission', which is useful given no annotations. However, it does not disclose other behavioral traits like nondestructiveness, rate limits, or whether changes affect other data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two brief clauses that front-load the verb and resource, with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and the straightforward nature of a query tool, the description covers the main actions adequately. Missing details like permission levels or pagination behavior, but acceptable for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already explains each parameter. The description adds minimal extra meaning (e.g., 'from changelist'), but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the main actions (list jobs from changelist, get job details) and indicates read-only via 'READ permission'. It clearly distinguishes from sibling tools that operate on other resources like reviews or files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like `query_reviews` or `modify_jobs`. No conditions or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'READ permission', indicating non-destructive behavior, which is useful. However, it does not disclose any other traits like response size limits, rate limits, or authentication requirements. The behavior is simple and the action enum fully specifies the operations, so a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose. It is not verbose and front-loads the key information. However, the title is null, and the description could be slightly expanded to improve usability without being wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and a probable output schema (not shown but implied), the description covers the essential purpose and permission. The input schema covers parameter semantics. It does not explain return values, but the output schema likely fills that gap. Overall, it is adequate for straightforward usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single parameter 'action' fully documented in the input schema, including explanations of both enum values. The tool description adds only 'READ permission', which is implied by the action names. No parameter details beyond the schema are provided, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get server info and current user information (READ permission)'. It specifies the verb 'Get' and the resources. The input schema further distinguishes two actions (server_info, current_user), making the purpose unambiguous. It also differentiates from sibling tools like query_streams and modify_streams by focusing on server-level metadata and user info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions 'READ permission', it does not explain when query_server is preferred over other query tools (e.g., query_streams). No exclusions or context for usage are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behaviors. It mentions 'WRITE permission' and lists actions (shelve, unshelve, update, delete, unshelve_to_changelist), but lacks details on consequences (e.g., what 'force' does, data loss risks). The warning 'use with caution' is in the schema, not description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence that efficiently conveys the core functionality. It is concise with no wasted words, though it could benefit from slightly more context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no annotations, and an output schema, the description is minimal. It covers the basics but does not explain return values (though output schema exists) or detail nuances like the difference between 'unshelve' and 'unshelve_to_changelist'. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description merely summarizes the actions (create/delete, update, unshelve) already detailed in the 'action' enum. It adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create/delete, update shelves and unshelve files', using specific verbs and the resource 'shelves'. It also notes 'WRITE permission', distinguishing it from the read-only sibling 'query_shelves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It only implies usage for shelf modifications. Sibling names like 'query_shelves' suggest a read/write split, but no clear guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure burden. It explains open vs closed states and permission, which is helpful. However, it does not disclose other behavioral traits like pagination, action-specific behavior, or result structure. The schema covers parameters but not behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—two sentences. The first sentence states purpose, the second adds valuable state definitions. No unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, 1 required, multiple actions, output schema exists), the description is too sparse. It does not guide how to use different actions (list, get, etc.) or differentiate from other query_ tools. Significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not add parameter-specific meaning beyond what the schema provides. The state definitions in description are about values, not parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get review details and list reviews (READ permission).' It distinguishes from sibling tools like modify_reviews (for writing) and other query_ tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies read-only usage via '(READ permission)' but does not explicitly state when to use this tool vs alternatives like modify_reviews or other query tools. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It mentions 'WRITE permission' and lists actions, but does not explain side effects (e.g., deletion consequences, submission requirements) or dependencies beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, concise and front-loaded with the main purpose. It could be slightly more structured (e.g., bullet list of actions), but it is efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 parameters, multiple action enums, output schema exists), the description covers the high-level purpose but lacks details on conditional parameter requirements and workflow steps. Still, it is largely sufficient for an agent with schema access.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds minimal value beyond the schema; it repeats action types but does not clarify parameter interactions or conditional requirements (e.g., file_paths needed for move_files).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's actions (create, delete, update, organize) on changelists, with 'WRITE permission' indicating the kind of operations. It distinguishes from sibling tools like query_changelists and other modify tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives. The description implies it is for changelist modifications, but does not mention when not to use it or suggest alternatives like query_changelists for reading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It mentions READ permission, which is basic transparency, but does not disclose rate limits, auth details beyond permission, or specific behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that captures the tool's core functionality. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return format is covered. However, the description lacks context on pagination, error handling, or typical use cases for each action, leaving some gaps for complex usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, so description adds minimal value beyond explaining the action parameter. The 'READ permission' tag does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists shelves, gets diff, and gets files, specifying READ permission. It distinguishes from sibling modify_shelves, which indicates a read-only purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates READ permission, implying read-only usage, and the schema provides action enum. However, it lacks explicit guidance on when to use this versus read-only query tools for changelists or files.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![p4mcp-server MCP server](https://glama.ai/mcp/servers/perforce/p4mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/perforce/p4mcp-server)

Score Badge

Copy to your README.md:

[![p4mcp-server MCP server](https://glama.ai/mcp/servers/perforce/p4mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/perforce/p4mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/perforce/p4mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server