Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
REGISTRY_PATHNoAbsolute path to local clone of the gen-e2-marketplace repository. Required for local/offline mode.
REGISTRY_GITHUB_REPONoGitHub repository path in owner/repo format for the marketplace (e.g., GLOBAL-PALO-IT/gen-e2-marketplace). Required for GitHub mode.
REGISTRY_GITHUB_TOKENNoOptional 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

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
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:

  • type: "skill", "agent", "command", or "hook"

  • plugin: plugin name (e.g. "android", "delivery", "research-suite")

  • tags: list of keywords (OR match — any tag must match)

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:

  • entry: structured RegistryEntry fields

  • metadata: parsed YAML frontmatter from the source file

  • content_raw: markdown body below the frontmatter (the actual instructions)

  • content_full: verbatim file content (frontmatter + body), write-ready

  • install_targets: exact destination paths per client (claude_local, copilot, plugin_tracking)

get_pluginC

Get all registry entries for a plugin, plus its manifest.

Returns:

  • manifest: Plugin metadata (name, version, description, tags)

  • entries: list of all RegistryEntry objects in the plugin

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:

  • name: artifact name (e.g. "research", "commit-push-pr")

  • type: "skill", "agent", "command", or "hook"

  • plugin: plugin name (e.g. "research-suite", "delivery")

  • local_version: version read from the local plugin.json (e.g. "0.8.0")

Returns:

  • outdated: entries where local_version != current registry version (includes registry_version)

  • unknown: entries not found in the registry

  • up_to_date_count: number of entries that match the registry

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:

  1. Read .claude/plugins//plugin.json → get local version

  2. Call check_compliance_plugin(plugin=, local_version=)

Returns the same shape as check_compliance:

  • outdated: artefacts where local_version != registry version (includes registry_version)

  • unknown: artefacts not found in the registry

  • up_to_date_count: number of matching artefacts

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:

  • added: entry IDs new in this reload

  • removed: entry IDs no longer present

  • modified: entry IDs whose plugin_version changed

  • total: total number of entries after reload

list_pluginsA

List all plugins with version, description, and entry counts per type.

Returns one entry per plugin sorted alphabetically, with:

  • name, version, description, tags, author

  • entry_counts: {skill, agent, command, hook, total}

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:

  • plugin: plugin name

  • version: current version

  • changelog_raw: full CHANGELOG.md text (null if absent)

get_marketplace_statsB

Get a dashboard overview of the entire registry.

Returns:

  • total_entries, total_plugins

  • by_type: entry counts per artifact type

  • by_plugin: per-plugin breakdown with version and counts

  • last_updated: most recent CHANGELOG date across all plugins

  • plugins_without_changelog: plugins missing a CHANGELOG.md

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".

  • task: natural language description of what you need

  • type: optional type filter ("skill", "agent", "command", "hook")

  • limit: max results to return (default 5)

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:

  • "I'm building an Android app" → android, delivery, architecture-reviewer

  • "I need to research and document a technical decision" → research-suite, delivery

  • "Go microservice with TDD" → go-tdd-orchestrator

  • task: natural language description of the project or need

  • limit: max results to return (default 5)

validate_entryA

Validate a skill/agent/command markdown file against the marketplace schema.

Checks required fields, recommended fields, body content, and naming conventions.

  • content: full file content including YAML frontmatter

  • type: "skill", "agent", "command", or "hook"

Returns:

  • valid: bool

  • errors: blocking schema violations

  • warnings: non-blocking recommendations

  • parsed: the parsed YAML frontmatter

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:

  • install a plugin into their project

  • get the documentation and install files for a plugin

  • know where to place a plugin's artefacts in their project

Returns all artefacts with:

  • content_full: verbatim file content (frontmatter + body), write-ready — use this to write the file directly without any reconstruction

  • install_targets: exact destination paths per client: claude_local → .claude/skills|agents|commands/{name}/... copilot → .github/skills|agents|prompts/{name}/... plugin_tracking → .claude/plugins/{plugin}/plugin.json

  • plugin_tracking: the plugin.json content to write for compliance tracking

Prefer this over multiple get_entry calls when working with a full plugin.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.9/5.0

Scored across 15 tools

Disambiguation4/5

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.

Naming Consistency5/5

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.

Tool Count4/5

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.

Completeness5/5

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.

Maintenance

ActivityMaintained
ResponsivenessNo issues