Skip to main content
Glama
Sign In
phabricator-mcp

phabricator-mcp

by freelancer
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

phabricator_transaction_search

Read-only

Search comments, status changes, and other transactions on a Phabricator object by its ID to review activity history.

Instructions

Search transactions (comments, status changes, etc.) on a Phabricator object (e.g., "D123", "T456")

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": {
      "objectIdentifier": "<objectIdentifier>"
    },
    "name": "phabricator_transaction_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
afterNoCursor for next-page pagination
limitNoMaximum results (max 100)
beforeNoCursor for previous-page pagination
constraintsNoSearch constraints
objectIdentifierYesObject ID (e.g., "D123", "T456") or PHID to get transactions for

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?

readOnlyHint=true already tells the agent this is a safe read. The description adds useful context about what 'transactions' means (comments, status changes) and that results are scoped to one object, but says nothing about ordering, return shape, or how pagination behaves beyond the schema's cursor fields.

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?

A single efficient sentence, front-loaded with the verb and resource, with the object-identifier examples placed naturally at the end. Every clause earns its place and there is no 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 a read-only search with full schema coverage and no output schema, the definition covers the call mechanics adequately. However, it gives no hint of what a transaction record contains or the ordering of results, which an agent might reasonably want given there is no output schema to lean on.

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 all five parameters (including the nested constraints and pagination cursors) are documented in the schema. The description only restates the objectIdentifier examples the schema already provides, adding no extra semantic detail. Baseline 3 applies when the schema does the heavy lifting.

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 (Search) and resource (transactions), clarifies the resource type with examples (comments, status changes), and gives concrete object-identifier examples ("D123", "T456"). It does not explicitly differentiate itself from sibling search tools like task_search or revision_search, keeping it just below 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase "on a Phabricator object" implies this is the way to get the activity/history for a specific object, but there is no explicit when-to-use/when-not guidance or named alternative. The agent must infer that for object-level history this is the tool, rather than the per-type *_search tools.

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