triage-mcp

check_existing_fix

Read-only

Determine whether a GitHub issue is already assigned or has open or merged pull requests referencing it, returning a clear status before you start a fix.

Instructions

Check whether an issue is assigned and whether open or merged pull requests reference it. Returns a verdict: unclaimed, assigned, open_pr_exists or already_fixed.

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": {
      "repo": "<repo>",
      "number": "<number>"
    },
    "name": "check_existing_fix"
  }
}

Input Schema

Name	Required	Description	Default
`repo`	Yes
`number`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 12, 2026

TDQS

B3.3/5.0

Behavior3/5

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

The supplied annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the useful behavioral detail that it queries both assignment state and PR references, and enumerates the four verdict outputs, which substitutes for the absent output schema. It does not mention rate limits, auth requirements, or whether the PR search is repo-scoped or broader.

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 tight sentences with the core check front-loaded and the verdict set appended; nothing is wasted. Slightly more structure (e.g., a sentence on what to do with the verdict) would have earned a 5.

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 small read-only check with two required parameters and no output schema, the description is close to sufficient: it explains what is inspected and names all four possible results. The remaining gap is that the distinction between 'open_pr_exists' and 'already_fixed' and the search scope are not spelled out.

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

Parameters2/5

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

Schema description coverage is 0% for two parameters, so the description carries the burden and largely fails it. The word 'issue' implies that 'number' is an issue number and 'repo' locates it, but neither parameter's format or semantics are clarified beyond the regex pattern already present in the 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 states a specific verb and resource: check whether an issue is assigned and whether open or merged PRs reference it. That scope is distinct from a plain issue fetch, but the description never explicitly contrasts itself with siblings like get_issue or search_issues, leaving the agent to infer the boundary.

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 rather than stated: an agent can infer this is a pre-work deduplication check, but there is no explicit 'use when' condition, no prerequisites, and no exclusion pointing at get_issue when full issue details are wanted.

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

Deploy Server