Gives any MCP client read-only access to the DecimalAI public skills registry through three tools.
search_skills: Search skills by keyword or natural language, with optional category, sort (recommended, lift, popular, top_rated, efficiency, rating, recent), and limit.
get_skill: Fetch a skill's full record by slug/UUID—trust/safety scan, verified benchmark lift, SkillScore, ratings, SKILL.md body, and install instructions.
get_leaderboard: Get ranked skills by skill_score, biggest_improvement, efficiency, or top_rated, with optional category, window_days, and limit.
Optionally set DECIMAL_API_KEY to see org-specific install status (installed_as); no key is required for public reads.
Point at a self-hosted backend with DECIMAL_API_URL.
It is read-only; it does not expose authenticated manifest-impact/regression-check.
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., "@decimalai-mcp search for web scraping skills and show the top ranked ones"
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.
Part of DecimalAI. Most users want the Python SDK → decimal-labs/decimalai-python.
MCP server for the DecimalAI skills registry — the registry that ranks agent skills by measured effectiveness (verified A/B benchmarks, live pass rates, AI rater scores), not download counts.
Gives any MCP client (Claude Desktop, Claude Code, Cursor, …) three read-only tools:
Tool | What it does |
| Hybrid keyword/semantic search over the public registry |
| Full record: trust & safety-scan status, verified benchmark lift, SkillScore, ratings, SKILL.md body, and how to install it ( |
| Ranked leaderboard: |
No API key required — all three tools read public registry endpoints. If you set DECIMAL_API_KEY (from app.decimal.ai/settings), the same tools additionally show which skills your org has already installed (installed_as).
pip install decimalai-mcp
# or, no install needed at config time:
uvx decimalai-mcpRequires Python 3.10+.
Related MCP server: Skills MCP Server
claude mcp add decimalai -- uvx decimalai-mcp
# with an API key:
claude mcp add decimalai -e DECIMAL_API_KEY=dai_sk_... -- uvx decimalai-mcpAdd to claude_desktop_config.json (Settings → Developer → Edit Config):
{
"mcpServers": {
"decimalai": {
"command": "uvx",
"args": ["decimalai-mcp"],
"env": {
"DECIMAL_API_KEY": "dai_sk_optional"
}
}
}
}Omit the env block entirely for anonymous read-only access.
Env var | Default | Purpose |
| (unset) | Optional. Unlocks per-org enrichment (e.g. |
|
| Point at a self-hosted / local backend. |
check_manifest_impact tool?The manifest-impact endpoint (POST /api/v1/regression-check) is authenticated on the platform — it analyzes your org's production traces against a candidate manifest, so there is no public variant to expose. This server is deliberately a read-only, key-optional public-registry surface. If demand shows up, an authed check_manifest_impact (requiring DECIMAL_API_KEY) is a natural v0.2 addition; the regression-check GitHub Action covers the CI use-case today.
GET /api/v1/registry/skills — browse/search
GET /api/v1/registry/skills/{slug} — detail
GET /api/v1/registry/leaderboard — ranked leaderboard (category filtering falls back to the browse endpoint's documented view=ranks mode, because the leaderboard endpoint is uncategorized)
pip install -e ".[dev]"
pytest # all HTTP mocked; no network
python -m decimalai_mcp.server # run over stdioRun pytest yourself before opening a PR. CI also asserts that the pinned mcp<2 still provides FastMCP, which the mocked tests do not cover — run that one too:
python -c "from mcp.server.fastmcp import FastMCP; import decimalai_mcp.server"Releases are cut from a published GitHub Release — see
RELEASING.md for the gates a
change has to pass and the version strings that must move together.
MIT
Ranked skills leaderboard.
Args: sort: skill_score | biggest_improvement | efficiency | top_rated. category: Optional category filter (uses the registry's ranked browse view — the dedicated leaderboard endpoint is uncategorized). window_days: Ranking window in days (1-3650; ignored for skill_score). limit: Max entries (1-50).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | biggest_improvement | |
| limit | No | ||
| category | No | ||
| window_days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior itself. It does add useful context: window_days is ignored for skill_score, and category uses the ranked browse view instead of the dedicated endpoint (which is uncategorized). This explains parameter interactions and a limitation. However, it does not explicitly state the tool is read-only, nor describe pagination or result ordering beyond the sort parameter, leaving some behavior implicit.
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 compact and well-organized. It leads with a one-line purpose, then uses a simple bullet-like list of parameters with inline explanations. No redundant fluff; every sentence 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?
An output schema exists, so return format details are not needed. The description covers parameter semantics and edge cases (e.g., ignored window_days, category behavior). Missing is a broader statement about when to leverage the leaderboard tool, but that's more under usage guidelines. For an agent to call it correctly, the parameter constraints and behavior are sufficiently specified. A minor gap is lack of mention of any permissions or side effects, but given the tool's nature, this is 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 description coverage is 0%, so the description is the sole source for parameter meaning. It thoroughly explains every parameter: sort options (skill_score, biggest_improvement, efficiency, top_rated), category as optional filter with a caveat about the endpoint, window_days range and the special case for skill_score, and limit range. This adds substantial value beyond the schema's bare types and defaults.
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 'Ranked skills leaderboard', which clearly indicates the tool returns a ranked list of skills. It distinguishes from siblings by name and content: search_skills and get_skill are about searching/retrieving individual skills, while this is explicitly a leaderboard. However, the phrasing is a noun phrase rather than a verb+resource construction, so it's not as explicit as 'Get ranked skills leaderboard'.
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?
No guidance is given on when to use this tool versus search_skills or get_skill. The description focuses solely on parameters and does not mention when a user should choose a leaderboard over a search or single-skill lookup. There's no discussion of use cases, exclusions, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one skill's full record: trust/safety-scan status, verified benchmark
evidence (lift vs no-skill baseline), SkillScore, ratings, the SKILL.md body,
and how to install it: its install name (the folder it installs into) and the
decimalai skills add <ref> command that writes that folder. The install part
is left out for a skill that is blocked or withheld, or whose safety scan is
flagged and awaiting review.
Args:
slug: The skill's url_slug from search results — NOT its name. A
registry name may be namespaced (owner/skill), and a slash cannot
survive a single URL path segment, so a namespaced name 404s here.
url_slug is the slash-free identifier minted for exactly this
(owner/skill -> owner-skill); for a plain un-namespaced name the
two are identical. The skill's UUID id also works.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 a conditional output shape (install info withheld for blocked, withheld, or safety-flagged-awaiting-review skills) and a concrete failure mode (namespaced name 404s, UUID id also accepted). It adds no auth, rate-limit, or caching context, but for a read tool the disclosure is otherwise substantial.
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 core purpose is front-loaded and the parameter caveats follow in a clearly labelled Args block. The opening sentence is a dense enumeration of return fields that could be tightened, but with 0% schema coverage the detail largely 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?
An output schema exists, so return-value explanation is not strictly required, yet the description still names the key fields and the one case where they are absent. The main remaining gap is that it does not say how to obtain a slug if the agent has not run a search.
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 0% for the single 'slug' parameter, so the description must compensate entirely, and it does: it distinguishes url_slug from name, explains the namespacing transformation (owner/skill -> owner-skill), explains why a slash 404s, and notes that the UUID id is also valid.
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 ('Get one skill's full record') and enumerates exactly what the record contains: safety-scan status, benchmark evidence, SkillScore, ratings, SKILL.md body, and install info. It ties itself to 'search results' but never names search_skills or get_leaderboard to explicitly draw the boundary, so it stops short of full sibling differentiation.
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?
Context is clear: this is the single-record lookup whose input comes from search results, and it tells the agent that install details are omitted for blocked/withheld/flagged skills. It does not explicitly state when to prefer this over the sibling list/leaderboard tools or how to obtain a slug if none is known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the public DecimalAI skills registry.
Args: query: Keyword or natural-language query (hybrid keyword/semantic search). category: Optional category filter (e.g. "retrieval", "code-review"). sort: recommended (SkillScore v2, default) | lift | popular | top_rated | efficiency | rating | recent. limit: Max results (1-50).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | recommended | |
| limit | No | ||
| query | Yes | ||
| category | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does add useful behavior details: 'public' registry, 'hybrid keyword/semantic search', and the recommended sort being 'SkillScore v2'. But it does not mention side effects, authentication needs beyond public access, pagination behavior, or what happens with empty results.
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 front-loaded with the core purpose, followed by a clean Args block. Every line adds value, the sort options are compactly listed, and there is no filler or repetition of schema defaults.
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?
The tool has a moderately sized parameter set and an output schema, so return values do not need to be described. The description covers all parameters, scope, and key behaviors. It could be slightly more complete by explicitly stating the relationship to sibling tools, but it remains sufficient for correct invocation.
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 0%, and the description fully compensates by documenting every parameter: query ('hybrid keyword/semantic'), category ('optional' with examples), sort (complete list with default), and limit ('Max results 1-50'). This adds meaning well beyond the bare schema property names.
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: 'Search the public DecimalAI skills registry.' This clearly distinguishes it from siblings like get_skill and get_leaderboard, which retrieve specific entities rather than perform a registry-wide search.
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 search intent is implied by the tool name and opening line, and the parameter docs clarify what filtering/sorting can do. However, there is no explicit guidance on when to choose search_skills over get_skill, nor any mention of 'use this to find skills, then get_skill for details.'
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.3get_leaderboardget_skillsearch_skillsScored across 3 tools
Each tool targets a clearly distinct action on the registry: fetch one skill by slug, retrieve a ranked leaderboard, and search the registry. Descriptions reinforce the boundaries (e.g. get_skill's note that slug is not the name), so an agent will not misselect among them.
All three names follow a clean verb_noun pattern (get_skill, get_leaderboard, search_skills) using snake_case consistently. The convention is predictable and readable.
Three tools is a small but coherent set for a read-only skills registry: discover (search), inspect (get), and rank (leaderboard). It is slightly thin — no category-listing or comparison tool — but each tool earns its place.
The surface covers the core discovery workflow: search, detail lookup (including install instructions), and ranked browsing. Minor gaps exist (no category enumeration, version history, or cross-skill comparison), but agents can work around them within the stated read-only scope.
Search and discover Agent Skills from the skills.sh registry. Powered by HAPI MCP server.
Discover and inspect public Runx skills before installing them. This read-only hosted MCP exposes search_skills and get_skill. The Apache-2.0 Rust runtime executes skills locally with scoped authority, approval gates and signed receipts. Docs: https://runx.ai/docs/mcp.
Search and fetch skills from your org's Skills and Agents catalog. Bearer token required.
Find AI agent skills: public previews and source links. Read-only discovery; no account required.
