Skip to main content
Glama
arbadacarbaYK

gittr-mcp

by arbadacarbaYK
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

listPRComments

Comments on a pull request, same as the website. A 64-character Nostr id returns Nostr comments. pr-N or a number needs ownerPubkey and repoId and returns the forge conversation. Nothing is posted back to GitHub.

Instructions

Comments on a pull request, same as the website. A 64-character Nostr id returns Nostr comments. pr-N or a number needs ownerPubkey and repoId and returns the forge conversation. Nothing is posted back to GitHub.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
prIdYesNostr pull request id, pr-N, or the forge number
limitNo
relaysNo
repoIdNoRequired with pr-N or a number
ownerPubkeyNoRequired with pr-N or a number

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.0.12
    • addedInput schema / properties / ownerPubkey
      Added value: +{
+  "description": "Required with pr-N or a number",
+  "type": "string"
+}
    • changedInput schema / properties / prId / description
      Previous value: -"PR event id (kind 1618)"New value: +"Nostr pull request id, pr-N, or the forge number"
    • addedInput schema / properties / repoId
      Added value: +{
+  "description": "Required with pr-N or a number",
+  "type": "string"
+}
  2. Addedv1.0.6

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the full disclosure burden. It usefully states 'Nothing is posted back to GitHub' (read-only) and that output content varies by identifier type, but says nothing about pagination, what limit/relays do, auth requirements, or result shape.

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?

Three dense sentences with the most important scoping facts front-loaded and no filler. 'Same as the website' is slightly informal but efficiently conveys the semantics.

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 read-only, five-parameter list tool with no annotations and no output schema, the description covers the critical input-routing logic and the read-only nature. The main omissions are the semantics of limit/relays and any pagination behavior.

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 only 60% (limit and relays are undocumented), but the description compensates by explaining the prId format options and the dependency rule that ownerPubkey and repoId are required with pr-N or a number. This adds real meaning beyond the raw 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 names a specific resource and operation — comments on a pull request — and clarifies the dual data source (Nostr id vs. forge conversation via pr-N/number). It implicitly distinguishes itself from the write sibling createPRComment by stating nothing is posted back to GitHub, though it never names an alternative tool directly.

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?

It gives conditional routing guidance: a 64-character Nostr id yields Nostr comments, while pr-N or a number requires ownerPubkey and repoId and returns the forge conversation. That is clear context for which input form to use, but it offers no explicit when-not or named-alternative guidance (e.g., listIssueComments for issue threads).

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