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 |
| 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: SkillFlow 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, and the SKILL.md body.
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 provided, the description carries the behavioral disclosure burden. It explains the 404 failure mode for namespaced names, clarifies the url_slug vs name distinction, and notes that the UUID also works. This goes well beyond a generic 'get' statement, though it doesn't address auth or rate limits.
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 tool's primary purpose and return contents, followed by a focused paragraph on the one parameter. Every sentence adds meaningful guidance that cannot be inferred from the minimal schema, with no filler.
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 read tool with an output schema, the description supplies all necessary context: what is returned, which identifier to pass, why other identifiers fail, and what works as an alternative. The agent has everything needed to call the tool 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 0%, so the description fully compensates. It explains what slug is, why the registry name may fail, how namespaced names map to url_slug, the URL-segment constraint, and that UUID is also accepted. This is exemplary parameter documentation.
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 ('Get one skill's full record') and enumerates exactly what the record contains: scan status, benchmark evidence, SkillScore, ratings, and SKILL.md body. This makes it immediately distinct from the sibling tools search_skills and get_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?
The description clearly directs the agent to use the skill's url_slug from search results instead of its name, which is essential operational guidance. It doesn't explicitly name alternatives or say when not to use this tool, but the context that this is a single-record fetch after search is clear enough.
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
search_skills and get_leaderboard both return ranked skill lists and accept category/sort filters, so an agent could initially confuse them; however, search_skills is query-driven and get_leaderboard is browse-oriented, and get_skill is clearly a detail lookup.
All tool names use the consistent verb_noun snake_case pattern (search_skills, get_skill, get_leaderboard), with clear and predictable prefixes.
Three tools is a well-scoped size for a read-only registry client: search, detail retrieval, and leaderboard browsing. There are no redundant extras or missing essential operations.
The surface covers the full read-only discovery lifecycle: find skills via search or leaderboard, then fetch full skill records. There are no obvious dead ends for the stated registry purpose.
Search and discover Agent Skills from the skills.sh registry. Powered by HAPI MCP server.
Search and fetch skills from your org's Skills and Agents catalog. Bearer token required.
A registry of 5,900+ peer-authored skills any MCP agent can search and load on demand.
The governed runtime for agent skills. Search the catalog and inspect a skill before running it.
