Skip to main content
Glama
Dmitry-Kaleykin

knowledge-gateway-mcp

by Dmitry-Kaleykin
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Local

skills-retrieval

A Pi package that discovers skills, uses Scribery for semantic retrieval and reranking, and activates selected skills through Pi's native skill pipeline.

It exposes exactly two model-facing tools:

  • search_skills searches eligible skill packages without revealing the full catalog;

  • load_skill activates a selected SKILL.md, or returns explicitly requested reference files from that skill.

When load_skill is called without files, it delegates to Pi's native /skill:name pipeline. The skill is therefore injected as a user-role skill message and displayed with Pi's normal collapsible skill widget. Requests for specific nested files, such as references/details.md, remain ordinary tool results.

Scribery is a private implementation detail. The package starts a read-only Scribery MCP subprocess with only list_documentation_sources and search_documentation enabled. Scribery's tools are never exposed to the model, and this project does not provide a public MCP server or executable.

Source policy

Every skill selected for retrieval must remain hidden from Pi's native model catalog:

---
name: example-skill
description: Specialized guidance for an example workflow.
disable-model-invocation: true
---

The source list of the configured Scribery documentation is the retrieval allowlist. A skill is eligible only when its directory has been added as a Scribery source, its SKILL.md is present in the active index, and it sets disable-model-invocation: true. Skills absent from that index remain available only through Pi's manual skill invocation.

Related MCP server: skill-retrieval-mcp

Automatic manifest

The in-memory skill manifest is built when Pi loads the extension and refreshed internally before every search or load. There is no manifest-management tool.

Discovery is recursive below the configured Pi skills root. Each directory containing SKILL.md becomes one skill package; nested files such as references/*.md, scripts, and assets belong to that package. File hashes are cached by size and filesystem timestamps during the extension lifetime. A package hash and whole-manifest hash change whenever relevant files change.

Scribery's active indexed-file inventory supplies each result's original absolute location. Skills Retrieval uses that location to map a hit in a nested reference back to the owning SKILL.md. Duplicate filenames therefore do not make skill selection ambiguous.

Prepare Scribery

In scribery-tui:

  1. Create documentation named pi-skills.

  2. Choose Configure sources → Add directory.

  3. Select one skill directory that should be retrievable, such as ~/.pi/agent/skills/example-skill.

  4. Give it a unique mount path, normally the skill name.

  5. Repeat for each skill you want in retrieval.

  6. Ensure the parent ~/.pi/agent/skills directory is not also configured as a source, which would index every skill and duplicate selected files.

  7. Choose Index documentation.

Use the same ordinary Index documentation action after skill files or the source list changes. Scribery discovers additions, modifications, and deletions while reusing unchanged chunks and embeddings.

Install in Pi

cd /Users/donais/Documents/Projects/skills-retrieval
npm install
npm run check
pi install /Users/donais/Documents/Projects/skills-retrieval

The Pi extension is generated at dist/skill-retrieval/index.js. Configure it through environment variables before starting Pi. For example:

export SKILLS_RETRIEVAL_SCRIBERY_COMMAND=/Users/donais/Documents/Projects/scribery/packages/scribery/dist/mcp.js
export SKILLS_RETRIEVAL_DOCUMENTATION=pi-skills
export SKILLS_RETRIEVAL_SCRIBERY_PROFILE=omlx-qwen3
export SKILLS_RETRIEVAL_SCRIBERY_API_KEY=omlx
pi

Available settings are:

  • SKILLS_RETRIEVAL_SKILLS_ROOT — defaults to $PI_CODING_AGENT_DIR/skills or ~/.pi/agent/skills;

  • SKILLS_RETRIEVAL_DOCUMENTATION — defaults to pi-skills;

  • SKILLS_RETRIEVAL_SCRIBERY_COMMAND — defaults to scribery-mcp;

  • SKILLS_RETRIEVAL_SCRIBERY_PROFILE;

  • SKILLS_RETRIEVAL_SCRIBERY_BASE_URL;

  • SKILLS_RETRIEVAL_SCRIBERY_API_KEY;

  • SKILLS_RETRIEVAL_SCRIBERY_RERANK_MODEL;

  • SKILLS_RETRIEVAL_SCRIBERY_RERANK_INSTRUCTION.

Use either a Scribery profile or explicit base-URL/reranking settings, not both.

Pi skill discovery must remain enabled. Individually indexed skills must still set disable-model-invocation: true; this hides their descriptions from Pi's model catalog without preventing the extension from invoking /skill:name.

Security boundary

  • Filesystem and Scribery operations are read-only. Native skill activation adds a user message to the current Pi session.

  • There is no list_skills, indexing, synchronization, or manifest tool.

  • Search is hard-scoped to indexed files owned by skill packages whose SKILL.md is indexed.

  • Skills omitted from the Scribery source list are neither searchable nor loadable through retrieval.

  • load_skill accepts only manifest-listed, skill-relative paths and rejects traversal, binary files, oversized files, and oversized combined responses.

  • The model cannot select documentation identifiers, provider settings, reranking settings, arbitrary source identifiers, or Scribery tools.

  • The selected skill is validated through retrieval policy before Pi expands it.

Available Tools

2 tools
load_skillLoad a found skillA
Read-onlyIdempotent

Load the complete skill for an exact skill name returned by search_skills.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesExact skill name returned by search_skills.
filesNoOptional skill-relative files to load instead of SKILL.md, such as references/api.md.

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds a meaningful precondition (exact name) and mentions loading the complete skill, but does not disclose return format or behavior when the name is not found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One front-loaded sentence with zero filler, placing the core action and the key precondition before anything else. It earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple load operation with a rich annotation set and fully described schema, the description plus schema cover the essential call context. The only minor gap is the absence of an explicit statement of what 'complete skill' returns, but no output schema was expected to be summarized.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and clearly documents both parameters, including the optional files parameter with an example. The description adds no parameter-level meaning beyond what is already in the schema, so it stays at the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Load') and resource ('the complete skill'), and scopes it to an exact name returned by search_skills. This clearly distinguishes it from the sibling search_skills, which is for finding skills rather than loading them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'exact skill name returned by search_skills' establishes the prerequisite workflow: call search_skills first, then load. It does not explicitly state when not to use the tool or name alternatives, but with only one sibling the routing is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_skillsSearch for a skillA
Read-onlyIdempotent

Search within local library of skills. Returns relevant candidates; it cannot list the complete skill catalog. Call load_skill for a relevant match.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of distinct skill candidates to return.
queryYesDescribe the user's task and the specialized guidance needed.

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey readOnly, idempotent, and non-destructive behavior, so the description does not need to restate those. It adds valuable behavioral context by explaining that the tool returns relevant candidates and explicitly cannot list the complete skill library, which is information not present in annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each earning its place: what the tool does, a key limitation, and the routing to the sibling tool. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple search tool with fully documented parameters, strong annotations, and one clearly identified sibling, the description covers what the tool does, its limitation, and the next step. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented meaningfully in the schema. The description does not add parameter-level detail, but it does not need to; the schema carries the semantic load. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Search within local library of skills.' It clearly distinguishes itself from the sibling load_skill by noting it returns candidates and cannot list the complete catalog, so an agent can tell search apart from load without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly directs the agent to 'Call load_skill for a relevant match,' establishing when to use this tool versus the sibling. The limitation statement also clarifies that search is not for enumerating the full catalog, which prevents misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0
Disambiguation5/5

search_skills handles discovery by returning candidate matches, while load_skill retrieves the full content for a specific skill name. Their purposes are clearly separated and complementary.

Naming Consistency5/5

Both tools use the same verb_noun snake_case convention, with search_skills and load_skill being predictable and consistent. The naming clearly indicates the action and target resource.

Tool Count4/5

Two tools is slightly below the typical range, but the server is intentionally scoped to a simple search-and-retrieve workflow. Each tool earns its place and there is no redundant surface.

Completeness5/5

For a read-only skill library gateway, the discover-then-retrieve flow is complete: search_skills finds relevant candidates and load_skill retrieves the full skill. No create, update, or delete operations are implied by the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • @skill-hub/mcp-server by skillhub-club

    @skill-hub/mcp-serverofficial

    skillhub-club
    A
    license
    A
    quality
    D
    maintenance
    Enables AI assistants to discover, search, and install Claude Code Skills from SkillHub, with tools for semantic search, browsing, recommendations, and installation.
    5
    45
    1
    MIT

  • skill-retrieval-mcp

    JayCheng113
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI agents to search and retrieve over 89K skills on-demand at runtime, eliminating the need to manually install skills upfront.
    108
    MIT

  • skill-router-mcp

    GitwithitDan
    A
    license
    Not graded
    quality
    B
    maintenance
    Exposes a 501-skill bundle as two tools: keyword search across skill metadata and retrieval of full skill text, enabling Claude to autonomously access and apply relevant skills.
    18
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Dmitry-Kaleykin/skill-retrieval'

If you have feedback or need assistance with the MCP directory API, please join our Discord server