Skip to main content
Glama
Sign In
CONTRI

CONTRI

by alphasafal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Can I take this issue?

check_issue
Read-onlyIdempotent

Determine whether a GitHub issue is free to take by reviewing assignees, claim comments, and linked pull requests, then return a clear verdict with evidence.

Instructions

Is this issue free to take? One verdict (Looks free, Claimed by @x, Claim went quiet, Open PR #n, Assigned, Closed, Partly checked) from assignees, claim comments and referencing PRs, with evidence links. 1–2 requests signed in, ~4 anonymous.

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": {
      "issue": "<issue>"
    },
    "name": "check_issue"
  }
}

Input Schema

NameRequiredDescriptionDefault
forceNoBypass the cache (costs requests)
issueYeshttps://github.com/owner/name/issues/123 or owner/name#123
detailNobrief: verdict + URL (~40 tokens); full: with evidence
includeThreadNoAlso return issue text and recent comments (up to ~14k chars)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already cover the read-only, idempotent, non-destructive, open-world profile. The description adds genuinely useful context beyond that: the closed verdict vocabulary, the evidence-link return, and the signed-in vs anonymous request cost, plus an implicit cache hinted at by the force parameter. It still leaves pagination/limits of the verdict derivation unstated.

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?

Two dense sentences, front-loaded with the decision question, then the return shape, then the cost. No filler, and the parenthetical verdict enumeration is the single most useful piece of information placed early.

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 no output schema, the description carries the burden of describing returns and does so by naming the verdicts and evidence links. Minor gaps remain around result freshness (beyond the cache hint) and what anonymous users lose, but an agent can call this correctly.

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 description coverage is 100%, so every parameter is already documented, and the description adds no parameter-level meaning beyond implying that results are cached and that cost varies with auth. The verdict list helps interpret output more than it helps set inputs, so the baseline 3 applies.

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 decision question ('Is this issue free to take?') and enumerates the exact verdict set it returns plus the evidence sources (assignees, claim comments, referencing PRs). This is far more than a restatement of the name, though it never explicitly contrasts itself with the sibling check_issues.

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?

The framing question makes the intended use case clear — pre-claim due diligence on a single issue — and the request-cost note helps an agent budget calls. It stops short of naming when to prefer check_issues or contribution_brief instead.

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