gittr-mcp

getIssueById

One issue, the way the website opens it. A 64-character id is the Nostr issue. issue-N or a number needs ownerPubkey and repoId and reads the forge issue.

Instructions

One issue, the way the website opens it. A 64-character id is the Nostr issue. issue-N or a number needs ownerPubkey and repoId and reads the forge issue.

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": {
      "issueId": "<issueId>"
    },
    "name": "getIssueById"
  }
}

Input Schema

Name	Required	Description
`relays`	No
`repoId`	No	Required with issue-N or a number
`issueId`	Yes	Nostr issue id, issue-N, or the forge number
`ownerPubkey`	No	Required with issue-N or a number

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.0.12Oct 15, 2026

addedInput schema / properties / issueId / description

Added value: +"Nostr issue id, issue-N, or the forge number"

addedInput schema / properties / ownerPubkey

Added value: +{
+  "description": "Required with issue-N or a number",
+  "type": "string"
+}

addedInput schema / properties / repoId

Added value: +{
+  "description": "Required with issue-N or a number",
+  "type": "string"
+}

First observedv1.0.3Jul 31, 2026

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses a dual-source behavior — a 64-char id resolves as a Nostr issue, while issue-N/number 'reads the forge issue' — which is real context beyond the schema. It omits auth requirements, auth-failure behavior, and any read-only confirmation, so it is only partially sufficient.

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?

Two short sentences with no padding; the conditional-parameter rule comes early. The opening clause is idiosyncratic but does not waste much space.

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?

No output schema exists, so the description could have said what a returned issue looks like or how the two resolution paths differ in result shape, and it does not. For a 4-parameter read tool it covers the input contract adequately but leaves the response side blank.

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 75% and already marks repoId/ownerPubkey as 'Required with issue-N or a number', but the description adds the *why*: the 64-char id is the Nostr issue while the other formats hit the forge, explaining the conditional requirement. This meaningfully frames the branching input contract.

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 resource (one issue) with a clear retrieval intent and explicitly contrasts itself with the plural listIssues-style siblings by naming the single-issue lookup. The phrase 'the way the website opens it' is colorful but adds little precision; still, an agent can tell this fetches one issue by identifier.

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?

Usage is implied through the id-format branching (64-char id vs issue-N/number), which tells the agent which path to take for each input shape. However, it never explicitly names alternatives like listIssues or getPullRequestById, nor does it state when this tool is the wrong choice.

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

Deploy Server