Skip to main content
Glama
Sign In
phabricator-mcp

phabricator-mcp

by freelancer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

phabricator_project_edit

Destructive

Create or edit a Phabricator project: set name, slug, description, icon, color, parent, milestone, space, and members, or omit the project identifier to create a new one.

Instructions

Create or edit a Phabricator project. Omit objectIdentifier to create a new project (name is required for creation).

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_project_edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
iconNoNew icon
nameNoNew name
slugNoProject URL slug (replaces ALL existing slugs with this one)
colorNoNew color
spaceNoSpace PHID (for multi-space installations)
parentNoParent project PHID (to create as a subproject)
milestoneNoParent project PHID (to create as a milestone of that project)
descriptionNoProject description (supports Remarkup)
addMemberPHIDsNoAdd members
objectIdentifierNoProject PHID or ID. Omit to create a new project.
removeMemberPHIDsNoRemove members

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.19

TDQS

A3.7/5.0
Behavior3/5

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

Annotations already flag this as non-read-only and destructive, so the safety profile is covered. The description adds one genuinely useful behavioral fact not implied by the schema — that all-optional parameters actually means 'create' when objectIdentifier is absent — but says nothing about destructive effects it can cause (removing members, replacing all slugs), permissions, or reversibility.

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, front-loaded with the action and immediately followed by the mode-switching rule. No restatement of the tool name or filler.

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 mutation tool flagged destructive, the description is thin: it omits how to identify the target project, that edits to unspecified fields are left untouched, and what the call returns. The rich schema and annotations carry most of the load, so this is adequate but not complete.

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 schema already explains slug replacement, member add/remove, parent vs milestone, etc. The only non-redundant contribution is the creation-time requirement for name, which the schema does not encode (required: []). That single fact justifies slightly above baseline but no more.

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+resource ('Create or edit a Phabricator project') and clarifies both modes live in one tool. It is distinguishable from the likely sibling phabricator_project_search, though it never names or contrasts with any sibling explicitly.

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?

Gives a concrete branch condition: omit objectIdentifier to create, and name is required in that case. It does not cover the inverse cases an agent might need — e.g. how to obtain an objectIdentifier (phid_lookup / project_search) or what happens when editing with no fields supplied.

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