Lab Registry Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| REGISTRY_PATH | No | Absolute path to local clone of the gen-e2-marketplace repository. Required for local/offline mode. | |
| REGISTRY_GITHUB_REPO | No | GitHub repository path in owner/repo format for the marketplace (e.g., GLOBAL-PALO-IT/gen-e2-marketplace). Required for GitHub mode. | |
| REGISTRY_GITHUB_TOKEN | No | Optional GitHub personal access token for private repos or higher rate limits. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_entriesA | List registry entries, optionally filtered by type, plugin, or tags. Use type="agent" to list agents, type="skill" to list skills, type="command" to list commands, type="hook" to list hooks. Omit all filters to list every entry in the registry. Filter by:
|
| search_entriesA | Search registry entries by exact keyword or partial name match. Searches name, description, and plugin name. Name matches are ranked before description matches. Optionally restrict results to a specific type. Use this when you have a specific keyword or partial name (e.g. "tdd", "android", "architecture"). For natural language task descriptions, use suggest_entries instead. |
| get_entryA | Get a specific registry entry with its full content. Use this ONLY when you already know the exact plugin, type, AND name of the artefact. If you only have a task description or keyword, use suggest_entries or search_entries instead to discover the right artefact first. To get all artefacts of a plugin at once, use get_plugin_install_package instead. Returns:
|
| get_pluginC | Get all registry entries for a plugin, plus its manifest. Returns:
|
| check_complianceA | Check whether locally installed gen-e2 plugin artefacts are up to date with the registry. Use this whenever the user asks to verify, check, or audit their installed gen-e2 plugins. Workflow: discover local plugin.json files (e.g. .claude/plugins/*/plugin.json), read the version field from each, then call this tool — do NOT compare versions manually. Each item in entries must have:
Returns:
|
| check_compliance_pluginA | Check all artefacts of a gen-e2 plugin against a single local version. Use this when you have a plugin.json with one version field and want to verify the whole plugin in one call, instead of listing artefacts manually and calling check_compliance with each one. Typical workflow:
Returns the same shape as check_compliance:
|
| reload_registryA | Force reload the registry from its source (GitHub or local path). Clears the in-memory cache and re-fetches all entries. Use after a marketplace update (git pull / new commit) to get fresh data without restarting the server. Returns a diff vs the previous state:
|
| list_pluginsA | List all plugins with version, description, and entry counts per type. Returns one entry per plugin sorted alphabetically, with:
|
| get_entry_by_idA | Get a registry entry by its full ID (plugin/type/name). Shortcut for get_entry when you already have the entry ID from list_entries. Returns same shape as get_entry: {entry, metadata, content_raw}. Example: id="android/skill/android-architecture" |
| get_changelogA | Get the full CHANGELOG.md content for a plugin. Useful after check_compliance signals an outdated entry — shows what changed between versions without leaving the MCP context. Returns:
|
| get_marketplace_statsB | Get a dashboard overview of the entire registry. Returns:
|
| suggest_entriesA | Suggest registry entries relevant to a natural language task description. Use this when you do NOT have a specific artefact name — only a task or intent description. It scores entries by term overlap and returns ranked suggestions. If you already know the exact plugin+type+name, use get_entry instead. For exact keyword or partial name matching, use search_entries instead. Examples: "I need to review architecture and create ADRs", "write tests for a Go service", "build an Android feature with MVVM".
|
| suggest_pluginsA | Suggest gen-e2 plugins relevant to a natural language task or project description. Use this for plugin-level discovery when the user describes their project or use case and wants to know which plugins are most relevant — before drilling into individual artefacts with suggest_entries. Scores plugins by how many task words appear in their name (3x weight), description, and tags. Returns plugins sorted by relevance score. Examples:
|
| validate_entryA | Validate a skill/agent/command markdown file against the marketplace schema. Checks required fields, recommended fields, body content, and naming conventions.
Returns:
|
| get_plugin_install_packageA | Get full documentation AND install-ready files for an entire plugin in one call. Use this whenever the user wants to:
Returns all artefacts with:
Prefer this over multiple get_entry calls when working with a full plugin. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 15 tools
Most tools target distinct operations (list/search/suggest entries vs plugins, compliance, validation, reload), and descriptions explicitly cross-reference when to use alternatives. However, several near-duplicate pairs exist (get_entry vs get_entry_by_id, get_plugin vs get_plugin_install_package, check_compliance vs check_compliance_plugin) that could be misselected despite the guidance.
Every tool follows a consistent snake_case verb_noun or noun pattern (get_* , list_*, check_*, search_*, suggest_*, reload_*, validate_*). No camelCase mixing or vague verbs; the longest names still conform to the same convention.
15 tools sit at the top of the well-scoped range and each maps to a plausible registry operation. A few are convenience wrappers (get_entry_by_id, check_compliance_plugin) that slightly inflate the count, but nothing feels gratuitous.
The surface covers the full lifecycle of a read-only marketplace: discovery (list/search/suggest for both entries and plugins), retrieval (entries, plugins, install packages), compliance checking, changelog, stats, schema validation, and cache reload. No obvious operational gaps remain for the agent's workflows.