Click on "Deploy 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-skills-mcp Find an issue in the scikit-learn repo for beginners"
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.
Guided open-source contribution skills, served as an MCP server.
The philosophy: the agent researches, you think and code. Each skill walks the agent through deep research for one stage of the contribution journey — finding issues, reading codebases, writing tests, responding to reviews — while the decisions and the code stay with you. The result is contributions that maintainers actually want to merge, from a human who actually learned the repo.
Works with any MCP client, including goose.
Evaluation
Skill | What it does |
| Assess a repo's health, governance, and trajectory before investing time |
The contribution workflow (roughly in order)
Skill | What it does |
| Find unclaimed issues filed by maintainers, matched to your skills |
| Read the contribution docs and fill knowledge gaps before coding |
| Get an unfamiliar repo building and testing locally |
| Research an issue deeply, then implement it yourself |
| Open a PR that follows the repo's guidelines |
| Understand review feedback and respond to it well |
| Diagnose CI failures in unfamiliar pipelines |
Contribution types
Skill | What it does |
| Add tests for untested code as a standalone contribution |
| Fix documentation gaps verified against the source |
Going deeper
Skill | What it does |
| Learn a codebase and build trust by reviewing others' PRs |
| Move from one-off contributor to regular |
| Find code problems that aren't in the issue tracker |
| Guided tour of a repo's architecture and patterns |
| Learn unfamiliar tech from how the repo actually uses it |
Related MCP server: oss-autopilot
uvx --from git+https://github.com/chiruu12/oss-skills-mcp oss-skills-mcpCLI
goose configureAdd a Command-Driven Extension with:
Name: oss-skills
Command: uvx --from git+https://github.com/chiruu12/oss-skills-mcp oss-skills-mcp
Desktop
Add a custom extension with:
Type: STDIO
Command: uvx
Arguments: --from git+https://github.com/chiruu12/oss-skills-mcp oss-skills-mcp
Each skill is available as an MCP prompt — invoke oss-find-issue,
oss-contribute, and so on from your client's prompt picker. Two tools are
also exposed for programmatic access:
list_skills() — names and descriptions of all bundled skills
get_skill(name) — full skill content
uv sync
uv run pytestMIT
Return the full content of a skill by name, e.g. "oss-find-issue".
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only indicates a read operation. Does not disclose behavior on missing names, required permissions, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 12 words, no unnecessary information. Action and resource are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations, the description suffices for a simple get operation. Output schema exists, so return values need not be explained. Could mention name exactness, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description adds value by specifying 'by name' and giving an example format. This clarifies the expected input beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action (Return), resource (skill), and parameter (by name) with an example. Distinguishes from sibling list_skills by emphasizing 'full content'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly for getting a single skill's content, while sibling list_skills lists skills. No explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the bundled OSS contribution skills with their descriptions.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It accurately describes a read-only list operation with no side effects. While minimal, it is sufficient for a simple, parameterless tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It front-loads the useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema and no parameters, the description is complete. It explains what the tool returns and is sufficient for an agent to understand its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema description coverage is 100%. The description does not need to add parameter information, earning the baseline score of 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'bundled OSS contribution skills', and adds that descriptions are included. It distinguishes itself from the sibling tool 'get_skill' which likely retrieves a single skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need to list all skills. However, no explicit guidance on when not to use it or comparisons to the sibling tool 'get_skill' are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0get_skilllist_skillsScored across 2 tools
The two tools have clearly distinct purposes: listing all skills vs. retrieving one by name. No overlap or ambiguity.
Both tools follow a consistent verb_noun pattern (list_skills, get_skill) with clear, predictable naming.
With only 2 tools, the server is minimal for its stated purpose. While the core operations are covered, the surface feels thin and could benefit from additional tools.
The tools cover the essential read operations for a static skills bundle: listing and retrieving details. Missing search or filtering, but not a critical gap for the domain.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Coordination hub for AI coding agents: message teammates, ask humans, audit every event.
Open-source SEO manager for coding agents: keyword research, content PRs, rank + Search Console.
Git-backed platform for skills, tools, and context for AI agents
