Skip to main content
Glama
Sign In
CONTRI

CONTRI

by alphasafal
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Can I take any of these issues?

check_issues
Read-onlyIdempotent

Check up to 10 GitHub issues in one call to confirm each is free to take before an agent starts work. Returns verdicts by default, with optional evidence and cache bypass.

Instructions

check_issue for up to 10 issues in one call, verdicts only by default. Same cost per 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": {
      "issues": "<issues>"
    },
    "name": "check_issues"
  }
}

Input Schema

NameRequiredDescriptionDefault
forceNoBypass the cache (costs requests)
detailNobrief: verdict + URL (~40 tokens); full: with evidence
issuesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already cover the safety profile (read-only, idempotent, non-destructive, open world). The description adds two behavioral facts the annotations do not: output defaults to verdicts only, and there is no per-call discount ('same cost per issue'). It does not disclose the cache relationship to check_issue, rate limits, or how partial failures among the 10 issues are reported.

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, batch scope and default output front-loaded, no filler. The opening 'check_issue' phrasing is slightly confusing next to the sibling tool of the same name and could be tightened.

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?

There is no output schema, so the description carries the burden of explaining returns, and 'verdicts only' is never defined (a verdict of what, per-issue and in what ordering). Cost and default-mode info are good, but the return shape is left for the agent to discover.

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 67%, so the baseline is 3. The description reinforces the 10-item cap and clarifies the default detail mode ('verdicts only by default'), which the schema's brief/full enum does not state. It says nothing about the force flag or what a verdict actually contains in each detail mode.

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 conveys a batch variant of check_issue: check up to 10 issues in a single call, returning verdicts by default. The verb 'check' is implied rather than stated outright, and the phrase 'check_issue for up to 10 issues' reads as if it were the sibling's name, but an agent can still tell this is the batch entry point versus the singular check_issue.

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 by 'up to 10 issues in one call' and 'same cost per issue', which suggests batching is free relative to calling check_issue repeatedly. However, no explicit when-to-use/when-not-to-use rule is given, and check_issue is not named as the alternative for the single-issue case.

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