taken
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TAKEN_CACHE_DIR | No | Override the cache directory for API responses (default: ~/.cache/taken) | ~/.cache/taken |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| check_issueA | Check whether a GitHub issue is already taken. Verdicts: GO (free to volunteer), TAKEN (spoken for: closed, open PR, or assignee), CAUTION (soft signal: someone expressed interest, the repo bans AI contributions, or the repo looks stale). The payload also carries Args: owner: repository owner login repo: repository name issue_number: issue number to check me: your GitHub login; your own comments are ignored in the claimant scan graphql: use the GraphQL fetch path (subprocess) instead of REST persistent_session: use the persistent-session GraphQL path instead of REST |
| scan_repoA | Scan a repository's open issues and recommend the GO ones. Results are ordered GO first, then CAUTION, then TAKEN, so the best
candidates to volunteer for come first. Args: owner: repository owner login repo: repository name limit: max open issues to check (default 20) label: only consider open issues carrying this label me: your GitHub login; your own comments are ignored in the claimant scan |
| discover_candidatesA | 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 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 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 3 tools
Each tool targets a distinct scope: check_issue handles a single issue, scan_repo covers a repository's open issues, and discover_candidates searches globally across GitHub. There is no overlap in their primary inputs or outputs, making selection unambiguous.
All three tool names follow the same verb_noun snake_case pattern: check_issue, scan_repo, discover_candidates. The verbs clearly indicate the action (check, scan, discover) and the nouns the target (issue, repo, candidates), maintaining a predictable convention.
With exactly 3 tools, the server is tightly scoped to its purpose of finding and vetting contribution-worthy issues. Each tool occupies a distinct niche (specific, repo-level, and global discovery), and no tool feels redundant or unnecessary for the domain.
The tool surface covers the full lifecycle of discovery and verification: global search (discover_candidates), repo-wide filtering (scan_repo), and per-issue assessment (check_issue). A minor gap is the lack of a tool to directly mark or claim an issue, but that is outside the stated purpose of evaluating availability, so the coverage is nearly complete.