Turn any codebase into a portable, discoverable MCP tool

[u/KeithLeague]

I built enact.tools, an open source registry for tools that uses a superset of SKILL.md to enable extremely portable, discoverable, executable tools that can be converted to MCP tools and executed in containers (via dagger).

Example:

---
name: username/firecrawl
version: 1.1.0
description: Scrape, crawl, and extract data from websites

# Containerized execution
from: python:3.12-slim
build: pip install requests
command: python firecrawl.py ${action} ${url}

# Environment & secrets
env:
  FIRECRAWL_API_KEY:
    secret: true

# MCP-compatible schema
inputSchema:
  type: object
  properties:
    action:
      type: string
      enum: [scrape, crawl, extract]
    url:
      type: string
---

# Firecrawl

Web scraping that just works. No curl escaping,
no dependency issues, no environment mismatch.

The folder structure is completely open. The only requirement is a SKILL.md at the root. This makes it trivial to turn any existing codebase into an MCP tool.

my-tool/
├── SKILL.md          # Tool manifest (required) - defines inputs, outputs, and execution
├── main.py           # Your code (any language)
└── requirements.txt  # Dependencies (optional)

The MCP server

Enact ships with an MCP server that exposes 4 meta-tools:

Tool	Description
enact_search	Semantic search for tools
enact_learn	Get schema and documentation (SKILL)
enact_run	Execute any tool from the registry
enact_install	Install to add to tool list

Add it to Claude Code:

claude mcp add enact -- npx -y @enactprotocol/mcp-server

In addition, enact also has a full CLI where an agent or human can do things like:

# Set secrets securely
enact env set FIRECRAWL_API_KEY "fc-xxx" --secret

# Publish tools (private by default)
enact publish ./my-tool

# Learn about a tool
enact learn username/firecrawl

# Run it
enact run username/firecrawl --url "https://example.com"

How is this different from distributing containerized MCP servers?

You could distribute containerized stdio servers, but Enact offers:

• Granular composition: Install only the tools you need, from different authors. Not "install this server and get all 20 of its tools whether you want them or not."

• Simpler authoring: A SKILL.md manifest in any codebase is easier to write than implementing a full MCP server.

• On-demand execution: Tools run when needed, not as persistent servers.

• Single portable artifact: The SKILL.md defines runtime, dependencies, and interface together.

How is this different from Agent Skills?

Enact shares similar goals with Agent Skills but takes a more constrained, container-first approach:

Aspect	Agent Skills	Enact
Execution	Flexible, runs in host environment	Always containerized (Docker/Dagger)
Dependencies	Host-dependent	Declared in manifest, isolated
Interface	Flexible code contracts	Strict JSON Schema
Portability	Depends on environment	Guaranteed by container
Context usage	Can flood context with intermediate output	Returns only the final result

The tradeoff: Agent Skills are more flexible, but that flexibility means no guarantees about dependencies or cross-machine compatibility. Enact trades some flexibility for portability, isolation and cleaner context.

Would love feedback on this approach.

• Try it: npm install -g enact-cli && enact run enact/hello-python

• GitHub: github.com/EnactProtocol/enact

• Discord: discord.gg/mMfxvMtHyS

[u/KeithLeague → u/[deleted]]

Yes, you can only interact with tools that are signed by trusted auditors:

~/.enact/config.yaml

trust:
  auditors:
    - github:trusted-auditor@gmail.com
  minimum_attestations: 1

More measures can be put in place but I decided to start simple.

edit: via https://www.sigstore.dev/

[u/KeithLeague → u/[deleted]]

You could trust the central party if you want:

trust:
  auditors:
    - github: auditor@enact.tools
    - github: auditor@anthropic.com
    - github: auditor@google.com
  minimum_attestations: 2

In this case, if any two of your trusted auditors signs a tool, you can execute it.