This MCP server lets an AI agent discover SkillGild skills, run prompt skills, start hybrid-tool sessions, call session tools, and end sessions.
Search the public SkillGild skill catalog by query; returns public metadata, access tier, version, and input schema, but not private prompts or implementation.
Run prompt_pipeline skills by public skill ID/slug with JSON input; sends input to SkillGild's AI provider, may consume allowance/entitlement, and returns generated output.
Start a session for a hybrid_tools skill; consumes one free/paid run, returns agent instructions plus available server tools, expiry, and tool-call limit, and returns the same open session at no extra cost if restarted.
Call a server tool in an open session using session_id, tool name, and input; input is processed only by SkillGild code, is not stored, and each call—even invalid—uses one session tool call.
End a session to invalidate its remaining tool calls.
SkillGild's local MCP server integrates with OpenAI's Codex CLI, letting Codex discover and run installed marketplace skills through tools such as skillgild_search_skills, skillgild_start_session, skillgild_call_tool and skillgild_end_session.
Production-ready AI agent skills, tools and developer workflows for Claude Code, Codex, Cursor, Gemini CLI and any MCP client. Your agent calls them, SkillGild runs them.
Website · Browse skills · Docs · Agent setup · Pricing · Learn
SkillGild is a marketplace for discovering, publishing and monetizing reusable AI agent skills, developer tools and workflows.
Developers install hosted skills into the coding agent they already use and call them through MCP.
Creators apply to publish their own skills and workflows for those agents to use.
Teams invite members to an organization and share the skills the organization unlocks.
Every developer ends up rebuilding the same prompts, workflows and integrations. On SkillGild, someone who knows the job well builds a skill once, and every agent that needs it can reuse it.
This repository is SkillGild's public home on GitHub: product overview, community guidelines, and the place to report issues and request features. It doesnot contain the SkillGild application source code or the contents of any marketplace skill.
Related MCP server: skills-master-mcp
The opening of the launch film. Watch the full film on the About SkillGild page, or download the MP4.
One SkillGild account and one connection work across agents.
Claude Code, Codex, Cursor and Gemini CLI connect through SkillGild's local MCP server. Any other client that can run a local stdio MCP server works too.
Discover AI agent skills | Explore AI agent skills by category, price and free runs, or start from a hand-picked collection. Categories include Development, Design, Research, Video & Media and Content Creation. |
Run free and Pro skills | Free skills include a monthly run allowance per skill. SkillGild Pro adds premium skills and server tools. Your AI subscription stays separate. |
Use the SkillGild CLI | One |
Connect through MCP | Your agent can search for skills, start a session, call server tools and end the session through the MCP tools. |
Build on the API | Call skills from your own code with the REST API and the TypeScript, Python and Go client libraries. See the developer quickstart. |
Publish a skill | Become a creator: apply, create a skill, write its protected prompt and submit it for review. |
Share with your team | Organizations let owners invite members and share the skills the organization unlocks. |
Refer and earn | The affiliate program pays commission on the Pro payments of people you refer. |
You set this up once per machine. After that, every skill is available to every connected agent. Full instructions: Connect your agent.
The skillgild CLI is both the sign-in tool and the local MCP server your agent talks to. It is a single binary with no dependencies.
macOS and Linux:
curl -fsSL https://raw.githubusercontent.com/SkillGild/skillgild/main/scripts/install-cli.sh | shWindows (PowerShell):
irm https://raw.githubusercontent.com/SkillGild/skillgild/main/scripts/install-cli.ps1 | iexThe installers download the latest release for your platform and check it against checksums.txt before installing. You can also download an archive from the releases page and put skillgild on your PATH.
skillgild loginThe CLI opens a device page in your browser. Check that the code matches (for example ABCD-EFGH) and click Approve. A revocable credential is saved to your operating system's credential store, never to a config file. Confirm with:
skillgild statusskillgild install brag --agent claude-codeUse --agent codex, cursor, gemini-cli, or shared (the default) to match your client. This example installs Brag, a free skill that turns your project into a short launch video.
claude mcp add --scope user skillgild -- $(command -v skillgild) mcpGuide: Install Claude Code skills
codex mcp add skillgild -- $(command -v skillgild) mcpGuide: Install Codex skills
gemini mcp add --scope user skillgild $(command -v skillgild) mcpGuide: Gemini CLI skills
Add this to ~/.cursor/mcp.json, or to .cursor/mcp.json in a project. Replace the path with the output of command -v skillgild:
{
"mcpServers": {
"skillgild": {
"type": "stdio",
"command": "/absolute/path/to/skillgild",
"args": ["mcp"]
}
}
}Guide: Cursor MCP setup
Start /absolute/path/to/skillgild mcp as a local stdio MCP server.
Guide: Add skills to a coding agent
Apps launched from an IDE may not inherit your terminal'sPATH, so use the absolute path from command -v skillgild. Never put an API key in MCP JSON or TOML, or in a repository. The MCP process reads its credential from the OS credential store.
Restart or reload your agent session. You should then see the skillgild_search_skills, skillgild_get_skill, skillgild_run_skill, skillgild_start_session, skillgild_call_tool and skillgild_end_session tools.
Prefer to let your agent do the setup? Paste this into Claude Code, Codex, Cursor or Gemini CLI:
Please set up SkillGild for me by following https://skillgild.dev/docs/quickstart-agents
Explain each step in plain language and ask me before running any command.skillgild mcp is a local stdio MCP server. It gives your agent six tools:
Tool | What it does |
| Search the catalog by task |
| Read one skill's public listing: access tier, input schema and server tools |
| Run a prompt skill and return its result |
| Start a session for a hybrid skill and receive its instructions |
| Call one of that session's server tools |
| End the session |
Claude Desktop: download skillgild.mcpb and open it; Claude Desktop installs the server and asks for your API key. It is also listed in the MCP Registry as io.github.SkillGild/skillgild.
The source is in cli/ (Go, MIT). Build it with cd cli && go build ./cmd/skillgild, or run it in a container with an API key from your account:
docker build -t skillgild .
docker run -i --rm -e SKILLGILD_API_KEY skillgildThe wrapper. skillgild install writes a small SKILL.md wrapper into your agent's skills folder. It holds public metadata and tells your agent when to use the skill and how to start it. It contains no private implementation.
Access check. When a task matches, your agent starts a session over MCP. SkillGild checks your account, entitlement and allowance first. Only then does it deliver the skill's protected instructions for that session.
Hybrid execution. Your agent does the work with its own model and tools, in your project. It calls SkillGild server tools for the private steps and shows you a diff before applying changes.
Protected prompts and server tool code are encrypted at rest and are not included in the installed wrapper. Hosted skills need an internet connection. To understand how this differs from an MCP server or a local skill folder, read Agent skills vs MCP servers and Free GitHub agent skills vs SkillGild.
Built a workflow that other developers' agents could use? Publish a skill on SkillGild:
Sign in with Google or GitHub and apply in Account → Creator studio.
Create a skill with a public listing and input schema.
Write its protected prompt. It is encrypted when you save it and is never shown to callers.
Submit it for review, then ship updates as new versions.
The SkillGild team reviews every creator application and skill. Upcoming creator features, including the creator dashboard, analytics and payouts, are tracked on the roadmap.
Free skills: sign in with Google or GitHub and run free skills with a monthly allowance that resets every month.
SkillGild Pro: premium skills and server tools, available monthly, quarterly or yearly. Prices and checkout follow your billing country.
Organizations: invite your team and share the skills your organization unlocks.
See pricing for current plans.
Get started
Quickstart for everyone: no coding needed
Quickstart for developers: API keys, sessions and SDKs
Quickstart for AI agents: CLI and MCP setup written for agents
Core concepts: free runs, paid access and devices
Learn about agent skills
Workflow guides
Compare
For agents and tools
llms.txt: site summary for LLMs and agents
Bugs and feature requests: open an issue in this repository.
Account, billing or a misbehaving skill: use the support center or email support@skillgild.dev.
Security issues: please don't open a public issue. See SECURITY.md.
Follow along: X · LinkedIn · Product Hunt
Before contributing, please read CONTRIBUTING.md and our Code of Conduct.
The contents of this repository are available under the MIT License. The license does not cover the SkillGild service, the SkillGild name and logo, or any skill published on the SkillGild marketplace. Each skill carries its own license, shown on its listing.
Call a server tool in an open SkillGild session. The input is processed by SkillGild code only, never by an AI provider, and is not stored. Each call, including one with invalid input, uses one of the session's tool calls.
| Name | Required | Description | Default |
|---|---|---|---|
| tool | Yes | tool name listed by the session | |
| input | Yes | input object matching the tool's input schema | |
| session_id | Yes | session ID from skillgild_start_session |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does add real value: input is handled only by SkillGild code, never an AI provider, is not stored, and every call including invalid input consumes a tool-call quota. It still omits failure semantics beyond quota (timeouts, expired session, whether the underlying tool's side effects occur).
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 short sentences with zero waste; the core action is front-loaded and the privacy and quota facts follow in order of importance. Nothing could be removed without losing disclosed behavior.
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 generic dispatcher with a nested input object, the definition covers privacy, storage, and quota cost, which are the non-obvious parts. It is slightly incomplete in not saying what the call returns (there is no output schema) or how an expired session or an invalid tool name surfaces to the caller.
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 all three required parameters (session_id, tool, input) are already documented in the schema. The description adds no syntax, format, or sourcing detail beyond it, so the baseline of 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 and resource: call a server tool within an open SkillGild session. It is distinguishable from lifecycle siblings (start/end session) and from skillgild_run_skill by its focus on invoking a tool listed by the session, though that contrast is only implied rather than stated.
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 phrase 'in an open SkillGild session' implies the prerequisite that a session must already exist, but there is no explicit when-to-use guidance and no comparison to skillgild_run_skill, which an agent may reasonably confuse it with. Usage is inferable, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End a SkillGild session when the task is done, so its remaining tool calls can no longer be used.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | session ID from skillgild_start_session |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does disclose the key consequence: remaining tool calls can no longer be used. It omits idempotency, permission requirements, and what happens on an invalid or expired session_id, which matter for a lifecycle-terminating mutation.
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?
One sentence, front-loaded with the action and the reason, with zero filler. It conveys purpose, timing, and consequence without repetition.
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 single-parameter lifecycle tool with no annotations or output schema, the description covers the essential outcome but leaves failure modes, idempotency, and post-end behavior of the session unspecified. It is adequate rather than complete.
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?
Only one parameter, and the schema already documents it at 100% coverage, including its provenance from skillgild_start_session. The description adds no further meaning about format or validation beyond the schema, so the 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?
The description names a specific verb (End) and resource (SkillGild session) and states the scope of what stops working afterward. Combined with the name skillgild_end_session, an agent can immediately distinguish it from start_session and the call/run/search siblings.
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?
It gives a clear trigger condition: 'when the task is done.' The paired sibling skillgild_start_session establishes the lifecycle implicitly. However, it does not address edge cases such as ending an already-ended session or when not to end one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a SkillGild prompt_pipeline skill by public ID/slug and JSON input. For hybrid_tools skills use skillgild_start_session instead. The input is sent to SkillGild's configured AI provider, may consume a free allowance or paid entitlement, and generated output is returned. Never send credentials or unrelated sensitive project data.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | input object matching the skill's public input schema | |
| skill_id | Yes | public SkillGild skill ID or slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that input is transmitted to an external AI provider, that execution may consume a free allowance or paid entitlement, and that generated output is returned. It omits failure modes, latency, and whether calls are idempotent or retryable, which matters for a billed operation.
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?
Four short sentences, front-loaded with the action and the routing rule, then the cost/external-provider disclosure, then the safety warning. Every sentence carries distinct information with no repetition of structured fields.
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?
Covers cost implications, external data transmission, and a data-handling warning, which is strong for a nested-input tool with no annotations and no output schema. The remaining gap is not pointing at how an agent discovers a skill_id or its input schema, which matters given the free-form nested object.
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 100%, so both parameters (skill_id, input) are already documented and the description only restates that input is JSON matching the skill's public schema. Baseline 3 applies; it adds no format examples or guidance on where to obtain a skill's public input 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?
States a specific verb and resource ('Run a SkillGild prompt_pipeline skill') plus the two identifying inputs (public ID/slug, JSON input). It also names the sibling it is not, distinguishing prompt_pipeline skills from hybrid_tools skills, so an agent can route without opening either schema.
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 an explicit routing rule: use skillgild_start_session instead for hybrid_tools skills, which is a real when-not condition. It does not mention skillgild_search_skills as the way to discover a valid skill_id, so the alternative-space is only partially covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search SkillGild's public skill catalog. Returns public metadata, access tier, version, and public input schema; never returns private prompts or implementation. Items with distribution_mode open_source are community skills listed with their source repository: they install from source with skillgild install <slug> and do not run on SkillGild.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | optional search phrase for hosted skills |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden and does well: it lists returned public metadata, access tier, version, and input schema, and explicitly says private prompts or implementation are never returned. It also explains the open-source distribution behavior, though it does not cover pagination, limits, or auth expectations.
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 first sentence front-loads the purpose, followed by return/privacy information and then the open-source caveat. All three sentences earn their place and there is no wasted preamble.
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 one-parameter search tool with no output schema, the description explains what is returned and what is deliberately not returned. The additional open-source distribution nuance gives the agent enough context to interpret results correctly.
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 the schema already documents the single query parameter. The description adds no additional query semantics, format guidance, or clarification that the schema marks query required while its property text says optional, so baseline 3 is appropriate.
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 and resource: search SkillGild's public skill catalog. The scope is clear and distinct from session/call/run siblings, so an agent can identify it without opening the schema.
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?
Explains that open-source results install from source with `skillgild install <slug>` and do not run on SkillGild, which is important usage context. It stops short of naming when to use this versus `skillgild_run_skill` or `skillgild_call_tool`, so it is clear but not fully directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a session for a SkillGild hybrid_tools skill. Uses one run from the user's free allowance or paid entitlement; while a session is open, calling this again returns it at no cost. Returns the skill's instructions for this agent to follow and the server tools it may call, with the session's expiry and tool call limit.
| Name | Required | Description | Default |
|---|---|---|---|
| skill_id | Yes | public SkillGild skill ID or slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the cost model (one run from free allowance or paid entitlement), the no-charge re-entry behavior while a session is open, and the contents of the response (instructions, permitted server tools, expiry, tool call limit). It stops short of saying what happens on expiry or what error states exist.
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, front-loaded with the action and resource, and every clause contributes concrete information (cost, idempotency, return contents). The second sentence is dense but not padded.
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?
No output schema exists, and the description compensates by enumerating what comes back. Together with the cost and idempotency notes, this is nearly enough to call the tool correctly; only lifecycle edge cases after expiry are left unstated.
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 100%, so skill_id's format ('public SkillGild skill ID or slug') is already documented in the schema. The description adds no further detail about the parameter, which is the expected baseline when the schema does the work.
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 and resource ('Start a session for a SkillGild hybrid_tools skill') and describes what the call yields (instructions plus server tools). It implicitly separates itself from skillgild_call_tool and skillgild_end_session by framing this as the session-opening step, though it never names a sibling explicitly.
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 qualifier 'hybrid_tools skill' hints at when this entry point applies, and the idempotency note ('calling this again returns it at no cost') tells the agent it is safe to re-call. However, there is no explicit routing versus skillgild_run_skill or skillgild_call_tool, and no statement of prerequisites.
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.0skillgild_call_toolskillgild_end_sessionskillgild_run_skillskillgild_search_skillsskillgild_start_sessionScored across 5 tools
Each tool has a distinct role: search, prompt-pipeline execution, hybrid-session lifecycle (start/call/end). The main possible confusion is between skillgild_run_skill and skillgild_start_session, but the descriptions explicitly route prompt_pipeline vs hybrid_tools skills, so boundaries remain clear.
All tools use a consistent skillgild_ prefix followed by a snake_case verb_noun pattern (search_skills, run_skill, start_session, call_tool, end_session). No mixed conventions or vague naming.
Five tools is well-scoped for this server: one discovery tool, two execution modes, and two session lifecycle controls. Each tool earns its place without redundancy.
The surface covers discovery, both execution modes, and session cleanup, which are the core workflows. Minor gaps exist, such as a dedicated get-skill-detail tool or entitlement inspection, but search and runtime responses provide enough metadata to work around them.
Agent skills for Claude, Codex and Cursor: find, install and load skills from one connector.
Agent-first skill marketplace with USK open standard for Claude, Cursor, Gemini, Codex CLI.
Search and load AI agent skills. Free metadata; full content requires a Pro or Studio account.
Find AI agent skills: public previews and source links. Read-only discovery; no account required.
