F
licenseB
qualityD
maintenanceEnables users to search and filter open source issues related to climate change and sustainability projects through the ClimateTriage API.
1
1
-
oss-issues-mcp
by AmrMohamed17
Provides triage-oriented GitHub issue tools: fetches issues with template scaffolding removed, checks whether an issue is already claimed via assignees and linked PRs, retrieves repository contributing rules, and lists new open issues across a watch-list.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@oss-issues-mcpshow me new open issues in my watch-list"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
oss-issues-mcp
An MCP server exposing derived, triage-oriented GitHub issue tools — not a passthrough of the GitHub API.
Where GitHub's own MCP server returns raw API responses, this server does task-specific work: stripping issue-template scaffolding, resolving whether an issue is already claimed from multiple signals, and filtering a watch-list of repositories to what is new and open.
Tools
Tool | Purpose |
| Fetch an issue, strip template furniture, return only triage-relevant fields |
(planned) | New open issues across a watch-list, pull requests excluded |
(planned) | Is this already being worked on? (assignees + linked PRs) |
(planned) | CONTRIBUTING.md and issue-template rules |
Related MCP server: my-github-mcp-server
Security
Repository allowlist — the server refuses any repo not explicitly allowed.
Read-only — no write tools exist until a human-approval gate governs them.
Requires a fine-grained, read-only
GITHUB_TOKEN.
Run
export GITHUB_TOKEN=github_pat_...
uv sync
uv run oss-issues-mcpLicense
MIT
Available Tools
4 toolsget_actionable_issueA
Fetch one issue, normalised for triage: template scaffolding stripped, only the fields a readiness judge needs (title, cleaned body, labels, author association, comments, state, url).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | "owner/name" on the allowlist, e.g. "mlflow/mlflow". | |
| number | Yes | the issue number. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses normalization behavior (template scaffolding stripped) and lists output fields, adding value beyond schema. However, it does not mention authorization, rate limits, or error conditions.
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?
The description is a single, concise sentence that front-loads the action and lists key details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description sufficiently covers the tool's purpose and output. It lists the key fields, and the schema provides the full structure.
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 100% and both parameters are described in the schema. The description does not add additional meaning to the parameters beyond the schema.
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 fetches one issue normalized for triage, listing the specific fields returned. It distinguishes itself from siblings like list_new_issues, which lists multiple 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 description implies usage for fetching a single issue for triage. Context from sibling tools (list_new_issues for listing, get_claim_status, get_repo_context) helps differentiate, but no explicit when-not or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_claim_statusA
Is this issue already being worked on?
Combines two deterministic signals GitHub does not expose as one field: formal assignees, and pull requests linked to the issue. Returns a boolean plus the evidence behind it. (Comment-based "I'll take this" claims are not checked in this version.)
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | "owner/name" on the allowlist. | |
| number | Yes | the issue number. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it combines two deterministic signals, returns boolean plus evidence, and explicitly mentions what is not checked (comment-based claims). This goes beyond minimal requirements.
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?
The description is very concise: a single sentence question captures purpose, followed by two sentences of elaboration. No unnecessary information, and key details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameters with full schema coverage and the presence of an output schema, the description provides complete behavioral context including limitations and return value format.
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 100% with clear descriptions for repo and number. The description does not add additional semantic detail beyond the schema, so baseline score is appropriate.
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 checks if an issue is being worked on by combining assignees and linked PRs. It uses a specific verb-resource combination and distinguishes from sibling tools like list_new_issues and get_repo_context.
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 implies usage to check before claiming an issue, but does not explicitly state when to use this tool versus alternatives. No exclusion criteria or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_repo_contextA
The repo's contribution rules: CONTRIBUTING.md presence/excerpt and whether issue templates are configured. Fetched once per repo and cached, since these rarely change.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | "owner/name" on the allowlist. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses caching behavior and infrequent changes, adding transparency. However, lacks details on error behavior (e.g., if repo not found) or auth requirements.
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 sentences concisely cover what the tool returns and caching behavior. Every sentence adds value with no redundancy.
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?
Output schema exists to handle return values, and description covers core behavior and caching. Minor lack of explicit edge cases (e.g., missing CONTRIBUTING.md) but overall adequate.
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 100% with one well-described parameter. The tool description adds no extra semantic detail beyond the schema, meeting baseline but not exceeding.
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 it fetches repo contribution rules (CONTRIBUTING.md and issue templates). This distinguishes it from siblings that focus on issues, making the purpose unambiguous.
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?
No explicit guidance on when to use this vs alternatives. Caching hint implies suitability for static repo info, but not directed to specific use cases like pre-issue creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_new_issuesA
New OPEN issues across the watch-list, pull requests excluded.
The single call that answers "what's new across everything I watch". Loops each repo, drops pull requests (the issues endpoint returns them too), and merges the results newest-first.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | look back this many days (by issue creation). | |
| repos | No | subset of the allowlist to check; defaults to all of it. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that it loops each repo, drops pull requests, and merges results newest-first. This gives good insight into internal behavior, though rate limiting or pagination details are missing.
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?
The description is concise and well-structured: two short paragraphs with the core purpose upfront. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, no annotations, and an output schema present, the description covers purpose, behavior, and parameters adequately. It is complete for an AI agent to understand usage.
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 100%, so the description adds only marginal value. It describes 'repos' as a subset of the allowlist, slightly beyond schema, but does not elaborate on 'days' beyond what's in schema.
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 verb 'list' and resource 'new OPEN issues across the watch-list', explicitly excluding pull requests. It distinguishes itself from sibling tools like get_claim_status and get_repo_context by focusing on listing new issues across watched repos.
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 description indicates it's the single call for what's new across watched repos, providing clear context. It doesn't explicitly state when not to use it, but sibling tools are different enough that confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
4 tool updates
v0.1.0- First observed
get_actionable_issue - First observed
get_claim_status - First observed
get_repo_context - First observed
list_new_issues
TDQS
A4.2/5.0
Disambiguation5/5
Each tool serves a distinct purpose: listing new issues, checking claim status, getting repo context, and fetching a single cleaned issue. No functional overlap.
Naming Consistency4/5
All names use snake_case and verb+noun pattern, but 'list' vs 'get' prefix is a minor inconsistency. Otherwise consistent.
Tool Count4/5
4 tools is small but focused on a specific triage workflow. Each tool earns its place; not too few for the domain.
Completeness4/5
Covers listing, claim checking, repo context, and fetching issues. Missing search or update capabilities, but adequate for read-only triage.
Maintenance
ActivitySlowing
ResponsivenessNo issues
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Manage repositories, users, releases, and automate GitHub workflows
Screens public GitHub repos and PRs to generate risk maps, findings, and merge-readiness signals.
Read-only GitHub bounty, agent harness, Actions failure, flake, and MCP tool-drift decisions.
Access the GitHub API, enabling file operations, repository management, search functionality, and…
Related MCP Servers
- FlicenseNot gradedqualityFmaintenanceProvides tools for managing GitHub sub-issues and milestones, including adding/removing sub-issues, getting parent issues, and setting milestones.-
- FlicenseAqualityCmaintenanceEnables LLMs to list, create, and comment on GitHub issues using your own GitHub identity via stdio transport.3-
- AlicenseNot gradedqualityCmaintenanceEnables AI assistants to discover, filter, and triage GitHub issues across repositories, with tools for fetching issue details, listing issues by state/labels, and finding related pull requests.1MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AmrMohamed17/oss-issues-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server