Community publishing is live

Why publish

Every operator configures similar tools, writes similar skills, and solves similar problems. Publishing turns that repeated work into shared infrastructure. When you publish an MCP server config that connects to Postgres, every operator who needs that connection saves the setup time. When you publish a code review skill, every team that adopts it gets a consistent review process. The value compounds as the community grows.

What you can publish

Anything you have built for your agents can become a community package. Ironspire supports five content types, each with its own packaging format and installation flow.

• MCP server configs: Pre-configured database connectors, API integrations, and development tools. Package your working server setup, including environment variable templates and connection parameters, so other operators can install it in one click and customise it for their own infrastructure.
• Skills: Reusable prompt templates for code review, documentation, testing, and analysis. Each skill defines a structured task that any agent can execute consistently. Skills include input schemas, expected output formats, and validation rules so results are predictable across different projects.
• Snippets: Shell scripts, config files, and utility functions for agent workflows. Small, focused pieces that solve specific problems: a git hook that formats commits, a cleanup script for build artefacts, a config template for CI pipelines.
• Presets: Complete agent configurations with curated tool sets, permissions, and project rules. A preset bundles everything an agent needs to specialise in a domain: the right MCP servers, appropriate permission levels, CLAUDE.md instructions, and recommended skills. Deploy a specialised agent in seconds instead of building one from scratch.
• Hooks and workflows: Automation triggers and multi-step task pipelines. Define what happens when an agent completes a task, encounters an error, or needs escalation. Chain multiple agents together with handoff rules, retry logic, and conditional branching.

How it works

Publishing follows a five-step pipeline. The entire process, from selecting content to a live listing, takes under a minute for most packages.

1. 1
   Package. Select the content you want to share. Ironspire bundles it into the .isp format with metadata, permissions, and version info. The packaging wizard detects your MCP servers, skills, and presets automatically; you choose what to include.
2. 2
   Sign. Keyless signing via Sigstore. No certificates to manage, no keys to rotate; your identity is verified through your existing GitHub or Google account. Every signature is recorded in a public transparency log.
3. 3
   Submit. One click submits your package for automated review. The SecurityScanner runs static analysis checking for obfuscated code, leaked secrets, unsafe patterns, and permission scope violations.
4. 4
   Review. Automated scanning completes in seconds. Packages that pass all checks are queued for publishing. If issues are found, you get a detailed report explaining what needs to change.
5. 5
   Publish. Your listing appears in the marketplace with your author profile, description, and trust indicators. Other operators can browse, review permissions, and install with a single click. Version history is preserved; you can push updates using semver.

Security model

Every community package is signed, scanned, and sandboxed before it reaches your agents.

• Sigstore keyless signing: Every package is cryptographically signed using Sigstore's keyless flow. No certificates to purchase or private keys to store. Signatures are recorded in a public transparency log, so anyone can verify who published a package and when.
• SecurityScanner: Automated static analysis runs on every submission. The scanner checks for obfuscated code, embedded credentials, known malware patterns, unsafe system calls, and overly broad permission requests. Packages that fail are rejected with detailed reports.
• Permission manifests: Each package declares exactly what it needs: file system access paths, network endpoints, environment variables, and shell commands. Operators review the manifest before installation. Nothing runs without explicit approval.
• Sandbox tiers: Packages run in isolation proportional to their risk level. High-risk packages that request network or shell access get Docker containers with resource limits. Low-risk packages with read-only file access get process-level sandboxing. The tier is determined automatically from the permission manifest.

Packages are signed via Sigstore, scanned for obfuscated code and leaked secrets, and sandboxed by risk tier.

Getting started

Update to the latest version, open the Marketplace tab, and click Publish. Your first package can be live in under a minute.

The publish wizard walks you through content selection, manifest review, and signing. Once submitted, automated scanning runs in the background and your listing goes live as soon as it passes.

Publishing requires Forge

What's next

Ratings, collections, and personalised recommendations are coming in the next release. We are also working on author analytics so you can see how your packages are being used across the community. The marketplace grows with every package you share.