phabricator-mcp

phabricator_repository_file_content

Read-only

Reads a repository file's text at a given path and commit or branch, with line-based paging for long files and metadata for binary files.

Instructions

Read a file's text at a path and commit/branch. Long files are paged: follow the closing note or set startLine/lineCount. A branch or other ref is resolved to a commit, which the note names so later pages read the same version. Binary files return metadata; files over byteLimit return tooHuge.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>",
      "commit": "<commit>"
    },
    "name": "phabricator_repository_file_content"
  }
}

Input Schema

Name	Required	Description
`path`	Yes	File path in the repository (e.g., "src/index.ts")
`branch`	No	Branch name
`commit`	Yes	Commit hash or branch name
`timeout`	No	Query timeout in seconds
`byteLimit`	No	Max file size in bytes (default 2097152)
`lineCount`	No	Lines to return
`startLine`	No	First line, 1-based
`repository`	No	Repository callsign, short name, or PHID
`startColumn`	No	Where to start in startLine, 1-based, in UTF-16 code units, as a previous note gives it

Schema Changelog

Changes observed during successful MCP inspections.

Changed6 schema fields changedv2.1.0Oct 22, 2026

changedInput schema / properties / byteLimit / description

Previous value: -"Maximum file size in bytes to return"New value: +"Max file size in bytes (default 2097152)"

addedInput schema / properties / byteLimit / minimum
```
Added value: +1
```
changedInput schema / properties / byteLimit / type
```
Previous value: -"number"New value: +"integer"
```

addedInput schema / properties / lineCount

Added value: +{
+  "description": "Lines to return",
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / startColumn

Added value: +{
+  "description": "Where to start in startLine, 1-based, in UTF-16 code units, as a previous note gives it",
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / startLine

Added value: +{
+  "description": "First line, 1-based",
+  "minimum": 1,
+  "type": "integer"
+}

First observedv2.0.19May 29, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=true, and the description adds substantial context beyond it: paging mechanics, ref-to-commit resolution so later pages read the same version, binary files returning metadata, and oversize files returning tooHuge. That is rich disclosure an agent cannot infer from the annotation.

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?

Four dense sentences, front-loaded with the core action and then edge-case handling. Every sentence earns its place (paging, ref resolution, binary, oversize) with no redundancy.

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?

With 9 params and no output schema, it covers paging and edge cases well, but it doesn't say what 'metadata' a binary file returns or the shape of the text payload. Slightly incomplete for a tool with no output schema, but adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds meaning by linking parameters to behaviors: startLine/lineCount drive paging, branch/refs resolve to commit, and byteLimit triggers tooHuge. It connects parameters into a coherent model rather than restating them.

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 and resource: 'Read a file's text at a path and commit/branch.' An agent can distinguish this from repository_browse and file_history. It doesn't explicitly name a sibling alternative, so it falls short of a 5.

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 concrete usage conditions: paginate long files by following the closing note or setting startLine/lineCount, and branch refs resolve to a commit for stable later pages. It doesn't state when to prefer code_search or browse instead, so no explicit exclusions.

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

Deploy Server