Skip to main content
Glama
Sign In
phabricator-mcp

phabricator-mcp

by freelancer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

phabricator_repository_edit

Destructive

Create a new Diffusion repository or update an existing one by setting version control, name, status, branches, projects, and other metadata via Phabricator.

Instructions

Create or edit a Diffusion repository. To create, omit objectIdentifier and provide vcs + name.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "phabricator_repository_edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
vcsNoVersion control system (required for creation)
nameNoRepository name
spaceNoSpace PHID (for multi-space installations)
statusNoRepository status
callsignNoRepository callsign (short uppercase identifier)
shortNameNoRepository short name (URL slug)
descriptionNoRepository description (Remarkup)
defaultBranchNoDefault branch name
addProjectPHIDsNoProject PHIDs to add
objectIdentifierNoRepository PHID, ID, callsign, or short name (omit to create new)
removeProjectPHIDsNoProject PHIDs to remove

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.19

TDQS

A3.5/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is known. The description adds the create-vs-edit branching behavior, but for a destructive mutation it never explains whether unspecified fields are preserved or cleared on edit, whether the change is reversible, or what permissions are needed — the most important behavioral question for this tool goes unanswered.

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?

Two sentences, roughly twenty words, with the primary action front-loaded and the mode rule immediately after. Nothing is padding; every clause carries 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?

For an 11-parameter, all-optional, destructive mutation with no output schema, the description is complete enough to select the right mode but not complete enough to call safely. The missing piece is edit semantics (patch vs. replace of the ten optional fields), which is precisely where an agent is most likely to cause unintended destruction.

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%, and the descriptions of vcs ('required for creation') and objectIdentifier ('omit to create new') already encode the rule the description restates. Baseline 3 applies: the description adds no parameter semantics beyond what the schema already provides.

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?

States a specific verb pair and resource: 'Create or edit a Diffusion repository,' and immediately disambiguates the two modes by naming the discriminating parameter (objectIdentifier). It does not name or exclude the obvious companion tool phabricator_repository_search, which is how an agent would obtain an identifier, so sibling differentiation is only partial.

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?

'To create, omit objectIdentifier and provide vcs + name' gives concrete mode-selection guidance, which matters for an 11-parameter tool with zero required fields. However, there is no guidance on the edit path — how to locate an existing repository, whether a search should precede an edit, or when to prefer this over any alternative — so usage is only half covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools