Skip to main content
Glama
RogueAlg0

taken

by RogueAlg0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

discover_candidates

Search GitHub for beginner-friendly issues, verify each with taken, and rank open-source contribution candidates by claim conflicts and welcoming signals.

Instructions

Discover top open-source contribution candidates.

Searches GitHub for good-first-issue style issues, runs taken's full verification on each, and returns the ranked candidates. Each result carries friendly_labels (first-time-contributor labels on the issue) and welcoming (repo-level signs contributions are welcome).

Error payloads carry error plus error_code: RateLimitError -> rate_limited, NotFoundError -> not_found, HTTP 401/CLI authentication failures -> auth_failed, subprocess timeouts -> timeout, other TakenError failures -> unknown.

Args: limit: max candidates to return (default 10) language: only consider repos in this language label: issue label to search (defaults to good-first-issue style labels) min_contributors: only consider repos with at least this many contributors in the last 90 days me: your GitHub login; your own comments are ignored in the claimant scan pr_idle_days: stale-claim decay threshold for idle linked PRs (default 90) claim_silence_days: stale-claim decay threshold for simple issues (default 7) claim_silence_complex_days: stale-claim decay threshold for complex issues (default 14)

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
meNoYour GitHub login; your own comments are ignored. Default: none.
labelNoIssue label to search. Default: good first issue, good-first-issue, beginner friendly, and help wanted.
limitNoMax candidates to return. Default: 10.
languageNoOnly consider repositories in this language. Default: no language filter.
pr_idle_daysNoStale-claim decay: days of linked-PR inactivity before TAKEN weakens to CAUTION. Default: 90.
min_contributorsNoOnly consider repositories with at least this many contributors in the last 90 days. Default: 0.
claim_silence_daysNoStale-claim decay: days one claim blocks as CAUTION on a simple issue; the clock resets on claimant activity. Default: 7.
claim_silence_complex_daysNoStale-claim decay: days one claim blocks as CAUTION on a complex issue. Default: 14.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.9.2
    • changedInput schema / properties / claim_silence_complex_days / anyOf
      Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "minimum": 0,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
    • changedInput schema / properties / claim_silence_days / anyOf
      Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "minimum": 0,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
    • addedInput schema / properties / limit / minimum
      Added value: +0
    • addedInput schema / properties / min_contributors / minimum
      Added value: +0
    • changedInput schema / properties / pr_idle_days / anyOf
      Previous value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "minimum": 0,
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]
  2. Changed3 schema fields changedv0.7.5
    • addedInput schema / properties / claim_silence_complex_days
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Stale-claim decay: days one claim blocks as CAUTION on a complex issue. Default: 14.",
+  "title": "Claim Silence Complex Days"
+}
    • addedInput schema / properties / claim_silence_days
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Stale-claim decay: days one claim blocks as CAUTION on a simple issue; the clock resets on claimant activity. Default: 7.",
+  "title": "Claim Silence Days"
+}
    • addedInput schema / properties / pr_idle_days
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Stale-claim decay: days of linked-PR inactivity before TAKEN weakens to CAUTION. Default: 90.",
+  "title": "Pr Idle Days"
+}
  3. Changed6 schema fields changedv0.7.2
    • addedInput schema / properties / label / description
      Added value: +"Issue label to search. Default: good first issue, good-first-issue, beginner friendly, and help wanted."
    • addedInput schema / properties / language / description
      Added value: +"Only consider repositories in this language. Default: no language filter."
    • addedInput schema / properties / limit / description
      Added value: +"Max candidates to return. Default: 10."
    • addedInput schema / properties / me / description
      Added value: +"Your GitHub login; your own comments are ignored. Default: none."
    • addedInput schema / properties / min_contributors
      Added value: +{
+  "default": 0,
+  "description": "Only consider repositories with at least this many contributors in the last 90 days. Default: 0.",
+  "title": "Min Contributors",
+  "type": "integer"
+}
    • removedInput schema / properties / min_stars
      Removed value: -{
-  "default": 0,
-  "title": "Min Stars",
-  "type": "integer"
-}
  4. First observedv0.5.0

TDQS

B3.4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does substantial work: it enumerates error codes (rate_limited, not_found, auth_failed, timeout, unknown) with the underlying failure types, and explains the stale-claim decay semantics. It stops short of stating that this is a read-only operation with no side effects on GitHub, which would round out the safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded and the error-code mapping is usefully compact, but the Args section duplicates parameter documentation that already exists verbatim in the schema at 100% coverage, adding length without new information.

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?

There is no output schema, so the description must explain return values, and it does: results carry friendly_labels and welcoming, and error payloads carry error plus error_code. It leaves the ranking methodology and the meaning of the TAKEN/CAUTION verdicts somewhat implicit, but the essential call-and-response contract is present.

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 the schema already documents all eight parameters including defaults, and the baseline is 3. The Args block largely restates the schema, adding only marginal value (e.g. clarifying that the user's own comments are ignored in the claimant scan), so it does not exceed the schema's contribution.

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 ('Discover top open-source contribution candidates') and details the mechanism (GitHub search plus taken's full verification, returning ranked candidates). It is clear on what the tool does, but never distinguishes itself from its siblings check_issue and scan_repo, leaving the agent to infer which tool to reach for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit when-to-use guidance, no prerequisites, and no mention of the sibling tools check_issue or scan_repo as alternatives. The description explains what happens internally but gives the agent no criteria for selecting this tool over the others.

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