Provides tools for searching GitHub repositories and code for SKILL.md files and MCP server configurations, and for downloading skill files from raw.githubusercontent.com to install into OpenCode projects.
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., "@opencode-skill-hub analyze this project and install the skills it needs"
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.
An MCP server (stdio transport) that acts as an automated skill and agent manager for OpenCode projects.
It answers three questions, in order:
What does this project need? — analyze_project_needs inspects dependency manifests and config files, then proposes the specialised skills/agents the project is missing.
Does it already exist? — search_skills_and_agents searches GitHub for real SKILL.md files and MCP server configurations.
Put it in place — install_skill_or_agent writes the skill to .opencode/skills/<name>/SKILL.md or registers the MCP server in opencode.json.
npm install
npm run build # tsc -> dist/Related MCP server: OpenCode MCP Server
Add the server to your project's opencode.json (see the bundled sample):
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"opencode-skill-hub": {
"type": "local",
"command": ["npx", "-y", "tsx", "src/index.ts"],
"enabled": true
}
}
}For a global install, register the compiled entrypoint instead:
"command": ["node", "/absolute/path/to/opencode-skill-hub/dist/index.js"]GITHUB_TOKENGitHub's code search API requires authentication, and it is the only way to find actual SKILL.md paths. Without a token the server still works — it falls back to repository search and says so in the tool output.
Variable | Purpose |
| PAT with |
| Used as a fallback if |
analyze_project_needs// input
{ "workspacePath": "C:/dev/my-app" }Scans package.json, Cargo.toml, pyproject.toml, go.mod, requirements.txt plus cross-cutting signals (Dockerfiles, tsconfig.json, prisma/schema.prisma, .github/workflows, monorepo manifests). Returns detected stacks, frameworks, dependency summaries, existing OpenCode assets, and a priority-ranked list of needs — each with a searchQuery you can feed straight into the next tool.
search_skills_and_agents// input
{ "query": "prisma migrations", "searchType": "all", "limit": 10 }
// searchType: "skill" | "mcp-server" | "all"Each result carries fullName, path, htmlUrl and a downloadUrl on raw.githubusercontent.com, so it can be piped straight into install_skill_or_agent.
install_skill_or_agent// install a skill
{ "workspacePath": "C:/dev/my-app", "itemType": "skill", "name": "prisma-migrations",
"sourceUrl": "https://raw.githubusercontent.com/owner/repo/main/.claude/skills/prisma-migrations/SKILL.md" }
// scaffold a skill locally (no download)
{ "workspacePath": "C:/dev/my-app", "itemType": "skill", "name": "my-convention" }
// register an MCP server
{ "workspacePath": "C:/dev/my-app", "itemType": "mcp-server", "name": "context7",
"mcpConfig": { "type": "local", "command": ["npx", "-y", "@upstash/context7-mcp"], "enabled": true } }skill → writes ${workspacePath}/.opencode/skills/${name}/SKILL.md. Omit sourceUrl to get a documented boilerplate with YAML frontmatter to fill in.
mcp-server → merges mcpConfig into ${workspacePath}/opencode.json under mcp.${name}, creating the file (with $schema) if needed and preserving every other key.
All logging goes to stderr; stdout is reserved for JSON-RPC.
name must match ^[a-zA-Z0-9][a-zA-Z0-9._-]*$, and the resolved skill path is re-checked against the skills root to block traversal.
Remote downloads are capped at 2 MiB, time out after 20 s, and are rejected if they look like an HTML error page or GitHub's 404: Not Found body.
A malformed opencode.json is never overwritten — the parse error is returned instead.
Every tool returns isError: true with a readable message rather than throwing across the transport.
npm run dev # tsx watch-free run of src/index.ts
npm run typecheck # tsc --noEmit
npm run build # emit dist/Scan a workspace's dependency manifests (package.json, Cargo.toml, pyproject.toml, go.mod, requirements.txt) and configuration files, then report the detected stacks, frameworks and dependencies along with the specialised skills and agents the project is likely to need. Call this first, before searching or installing anything.
| Name | Required | Description | Default |
|---|---|---|---|
| workspacePath | Yes | Absolute path (or path relative to the home directory) of the project to analyze. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It discloses the read surface (manifest and config files scanned) and the nature of the result (detected stacks plus recommended skills/agents), which makes clear this is a non-mutating analysis step. It does not explicitly state that it is read-only or what permissions the path requires, leaving a small gap.
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?
Two sentences, no filler, with the operation front-loaded and the invocation directive placed at the end where it is most actionable. Every clause earns its place by naming either the inputs or the outputs.
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?
With no output schema, the description compensates by enumerating what the report contains (stacks, frameworks, dependencies, recommended skills and agents), which is enough for an agent to know what it gets back. It does not mention failure modes for a missing or invalid path, a minor omission for a single-parameter tool.
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 is a single parameter and schema description coverage is 100%, so the schema already documents workspacePath fully. The description adds no path syntax or resolution detail beyond the schema, which matches the baseline of 3 for high-coverage schemas.
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?
States specific verbs (scan, report) and concrete resources: the exact dependency manifests and config files it inspects, plus the four classes of output (stacks, frameworks, dependencies, recommended skills/agents). An agent can distinguish it from search_skills_and_agents and install_skill_or_agent purely from this sentence.
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?
Gives explicit ordering relative to its siblings: "Call this first, before searching or installing anything." This routes the agent away from search_skills_and_agents and install_skill_or_agent until this has run, which is exactly the when-to-use guidance needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install a skill or register an MCP server into an OpenCode workspace. For itemType='skill' this writes ${workspacePath}/.opencode/skills//SKILL.md, downloading it from sourceUrl or generating a documented boilerplate when sourceUrl is omitted. For itemType='mcp-server' this merges mcpConfig into ${workspacePath}/opencode.json under mcp., creating the file when needed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Identifier for the skill directory or the mcp config key. Letters, digits, dots, underscores and dashes only. | |
| itemType | Yes | What to install. | |
| mcpConfig | No | MCP server entry to merge into opencode.json, e.g. {"type":"local","command":["npx","-y","my-server"],"enabled":true}. Omit to receive a placeholder entry. | |
| sourceUrl | No | Optional http(s) URL of a SKILL.md to download. GitHub blob/API URLs are automatically converted to raw URLs. Omit to generate a boilerplate skill. | |
| workspacePath | Yes | Absolute path (or path relative to the home directory) of the target project. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full load and does so well: it names the exact files written, the merge target path (mcp.<name> in opencode.json), file creation behavior, URL downloading with GitHub blob-to-raw conversion, and boilerplate/placeholder generation when optional inputs are omitted. It omits overwrite/failure/reversibility semantics and result reporting, which keeps it short of a 5.
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?
Two dense sentences, purpose front-loaded before the mode-specific details, and no filler. It is information-heavy but every clause earns its place.
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?
For a write tool with no annotations and no output schema, the description covers the write targets and fallbacks thoroughly but says nothing about what is returned, whether an existing SKILL.md is overwritten, or how merge conflicts on mcp.<name> are resolved. Those gaps are the ones an agent would most want filled.
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 coverage is already 100%, so the baseline is 3; the description earns extra credit by explaining how parameters interact across modes — sourceUrl and mcpConfig matter only for their respective itemType, and omitting each triggers a documented fallback. That is meaning beyond the per-field schema text.
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 opens with a specific verb and resource ('Install a skill or register an MCP server') into a named target ('an OpenCode workspace'), and then splits the two modes explicitly. This lets an agent distinguish it immediately from siblings like search_skills_and_agents (discovery) and analyze_project_needs (analysis).
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?
The two itemType branches imply when each mode applies, and the sourceUrl/mcpConfig fallbacks hint at usage, but there is no explicit statement of when to choose this tool over the sibling search/discovery tools. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search GitHub for reusable OpenCode/Claude skills (SKILL.md files) and MCP server configurations matching a query. Returns repository, file path and a raw download URL for each match. Set GITHUB_TOKEN in the server environment to enable code search (required for finding actual SKILL.md files).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| query | Yes | Free-text search query, e.g. "prisma migrations" or "playwright e2e". | |
| searchType | No | Restrict the search to skills, MCP servers, or both. | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and handles the most important operational gotcha: code search requires GITHUB_TOKEN in the server environment, implying degraded results without it. It also discloses the return shape (repository, file path, raw download URL). It omits rate limits, pagination behavior, and failure modes, keeping it short of a 5.
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?
Three sentences, each doing distinct work: what is searched, what comes back, and the environment prerequisite. Front-loaded with the action and resource, and no filler or repetition of the name.
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?
There is no output schema, but the description compensates by naming the returned fields. Combined with the token prerequisite and 100% parameter coverage, an agent has what it needs to call the tool; only rate-limit and pagination details are absent.
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 description coverage is 100%, so query, limit, and searchType are already fully documented, including the enum values. The description restates the query concept and the skill/MCP-server split but adds no syntax, formatting, or matching semantics beyond the schema, so baseline 3 applies.
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?
States a specific verb (Search) and resource (GitHub for OpenCode/Claude skills and MCP server configs) with clear scope, including what a match contains. It does not explicitly distinguish itself from the siblings analyze_project_needs or install_skill_or_agent, though the search-vs-install distinction is reasonably self-evident from the verb.
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?
The description never says when to reach for this tool versus analyze_project_needs or install_skill_or_agent, and offers no exclusions or workflow context. The only conditional guidance ('Set GITHUB_TOKEN...') is a setup prerequisite rather than usage direction.
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.0analyze_project_needsinstall_skill_or_agentsearch_skills_and_agentsScored across 3 tools
The three tools map to a clean sequential workflow: analyze the project, search for matches, then install. Each has a clearly distinct verb and target, so an agent can easily pick the right one with no overlap.
All three follow a consistent verb_noun snake_case pattern (analyze_project_needs, search_skills_and_agents, install_skill_or_agent). Predictable and readable throughout.
Three tools form a coherent discover-then-install pipeline where each earns its place, though the surface is on the lean side. A list/remove capability would round it out.
The read-then-write lifecycle (analyze, search, install) is covered, but there is no way to list already-installed skills/servers, update them, or uninstall them. These notable gaps mean agents can add but not manage or clean up.
Search, fetch, lint, and install Agent Skills (SKILL.md) from the SkillMD registry.
Search and fetch AI agent skills, rules files and MCP servers indexed from GitHub.
Search and discover Agent Skills from the skills.sh registry. Powered by HAPI MCP server.
Your OpenWork org's skills, plugins, workflows, and connections through one OAuth MCP URL.