It lets coding agents (Claude Desktop, Cursor, Cline, ...) search the Crela marketplace and publish software to it, straight from a conversation. Under the hood it wraps the Crela public search API and the authenticated Agent API.

Install

No install needed - run it via npx:

npx @crela/mcp

Configure

Add the server to your agent's MCP config. Example for Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "crela": {
      "command": "npx",
      "args": ["-y", "@crela/mcp"],
      "env": {
        "CRELA_API_KEY": "crela_..."
      }
    }
  }
}

CRELA_API_KEY - required only for the publish tools. Create one at https://crela.io/dashboard/creator/keys. Search tools work without it.
CRELA_BASE_URL - optional, defaults to https://crela.io.

Tools

Discovery (no API key)

Tool	Description
`search_software`	Search approved software by query, category, language, sort, page.
`get_software`	Full public detail of one software by slug.
`get_submission_requirements`	Machine-readable submission rules - call this before submitting.

Publish (needs `CRELA_API_KEY`)

Tool	Description
`list_my_software`	List all software you own with id, slug, review status, unlisted flag, price and sales count. Recovers the software id the other tools need.
`precheck_build`	Dry-run the submit gate on a build ZIP without creating a listing: framework detection, bundle completeness, SDK marker (KO-10) and file-count limit. Returns pass/fail plus missing files - fix before submitting. Not the full review. The response carries `storage_path`: hand it to `submit_new_software` or `update_software` and the ZIP is not uploaded twice.
`preview_marker`	Compute the SDK marker (KO-10) for a planned slug - embed it in a paid tool's binary before submitting.
`get_sdk_marker`	Fetch the SDK marker of an existing tool - embed before uploading a new paid build.
`submit_new_software`	Submit a brand-NEW software listing: build ZIP plus metadata; returns the tool id and review job id. Use only for a tool that has never existed before — not for uploading a new version of an existing one. Optional `entrypoint`/`framework`/`platforms`/`os`/`arch` overrides for when auto-detection is wrong or ambiguous.
`update_software`	Replace the build binary of an EXISTING software with a new version. Handles presign -> direct R2 upload -> finalize, so large builds do not hit the upload timeout. `channel: "demo"` publishes a demo without touching the live listing.
`set_metadata`	Change metadata of an existing software — no binary upload, no ZIP. Covers title/description/price, sales (`sale_price_eur`/`sale_ends_at`), trials (`trial_enabled`/`trial_days`), `max_devices`, license, install type, categories, tags, `privacy_policy`, `support_contact`, `platforms` and `unlisted`. Set `unlisted: true` to take an approved tool off the market (reversible) - buyers keep access, it just cannot be newly purchased.
`check_review_status`	Poll the lightweight review status (progress, sub-step, rate limit).
`get_review_report`	Full review report: pass/fail, rejection reasons, findings to fix. Locations are capped at 10 per finding so a CVE report cannot flood the agent's context; raise `max_locations_per_finding` for the long tail.
`get_my_software_details`	Full metadata plus media list (with ids) of one of your own tools, any status - use before editing media or metadata.
`upload_screenshot`	Upload a screenshot or logo image from a local file path. JPG/PNG/WebP/GIF, max 5 MB - format and size are checked before anything is uploaded.
`update_media`	Change the sort order of any media item, or the URL of a video entry.
`delete_media`	Delete a screenshot, logo or video entry from a listing.
`delete_software`	Permanently delete a software - only if it was never sold (sold tools return 409; unlist them instead).

Typical publish flow

get_submission_requirements - learn the rules and required fields.
precheck_build - dry-run the submit gate; fix any missing files/marker before spending a review cycle.
submit_new_software - metadata plus the build. Pass the storage_path from step 2 instead of file_path and the ZIP travels once, not twice.
upload_screenshot - at least 3 images; the review agent scores presentation on them.
check_review_status / get_review_report - poll until the review completes; fix and resubmit on failure.

Shipping something with analytics or telemetry? Set privacy_policy (on submit or via set_metadata) and name the service in it - KO-09 rejects builds whose code contacts a tracker the policy does not mention.

Lost track of a tool id? list_my_software returns every tool you own with its id and current status.

Shipping a new version

Once a tool exists, ship a new build with update_software (software id + file_path or a storage_path from precheck_build, plus version/os/arch). Versions are semver and validated locally, so a v1.7.5 is rejected before the upload rather than after it. A release build sends the tool back into review; poll with check_review_status as above.

Development

The tool input schemas mirror the Crela review pipeline's server-side whitelists (frameworks, categories, install types, DRM modes, arch aliases, patchable metadata fields). Two guardrails keep them from drifting apart as the pipeline evolves:

Test/unit/mcp-server-parity.test.ts (in the main repo) diffs this package's enums against the canonical server sources and fails when the server gains a value this package doesn't know.
npm run verify:npx packs the tarball, installs it into a throwaway project and drives the installed binary over the real MCP stdio client - the same path npx @crela/mcp takes - so what ships behaves like what runs here. It is part of prepublishOnly.