Skip to main content
Glama
RogueAlg0

taken

by RogueAlg0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

discover_candidates

Find GitHub issues suitable for first-time contributors, run verification on each, and return ranked candidates with welcoming repo 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).

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

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.
min_contributorsNoOnly consider repositories with at least this many contributors in the last 90 days. Default: 0.

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
-}
  2. First observedv0.5.0

TDQS

A3.6/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds context beyond the schema by mentioning 'runs taken's full verification' and that the agent's own comments are ignored in the claimant scan. It also describes result fields (friendly_labels, welcoming). However, it does not explicitly state whether the operation is read-only, any side effects, or potential rate limits. It's adequate but not rich.

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?

The description is well-structured: a concise overview sentence followed by a bullet-style Args section. It front-loads the core purpose and avoids excessive verbosity. The Args list duplicates schema info but is compact and readable, earning its place by providing quick reference without being bloated.

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?

The tool has 5 parameters, no output schema, and no annotations. The description explains the outcome (ranked candidates with specific fields) but does not detail the verification process, pagination, or return format beyond the mentioned fields. It is sufficient for basic usage but leaves some context (e.g., authentication, errors, timeouts) uncovered. Given the complexity, a 3 is fair.

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?

The schema description coverage is 100%, so the schema fully documents all five parameters. The description's Args section largely repeats the schema descriptions (e.g., 'me: your GitHub login; your own comments are ignored' also appears in the schema). It adds minimal new meaning, so a baseline of 3 is appropriate given the high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Discover top open-source contribution candidates.' It then specifies the method: 'Searches GitHub for good-first-issue style issues, runs taken's full verification on each, and returns the ranked candidates.' This verb+resource combination distinguishes it from siblings (check_issue, scan_repo) by focusing on discovery and ranking rather than single-issue checks or repo scans.

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?

The description explains what the tool does but does not explicitly state when to use it vs. alternatives. It implies usage for discovering candidates, but there is no mention of exclusions or conditions that would route an agent to check_issue or scan_repo instead. The guidance is adequate but not explicit enough for a 4.

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