AceDataCloud AI Generators

Monorepo for all AceDataCloud MCP (Model Context Protocol) servers.

Servers

Directory	Standalone Repo	PyPI Package	Category	Documentation
acedatacloud/	AceDataCloudMCP	mcp-acedatacloud	Account	Documentation
face/	FaceTransformMCP	mcp-face-transform	Vision	Service details
fish/	FishMCP	mcp-fish	Audio	Documentation
flux/	FluxMCP	mcp-flux-pro	Image	Documentation
hailuo/	HailuoMCP	mcp-hailuo	Video	Documentation
happyhorse/	HappyHorseMCP	mcp-happyhorse	Video	Documentation
kling/	KlingMCP	mcp-kling	Video	Documentation
luma/	LumaMCP	mcp-luma	Video	Documentation
maestro/	MaestroMCP	mcp-maestro	Video Production	Documentation
midjourney/	MidjourneyMCP	mcp-midjourney	Image	Service details
nanobanana/	NanoBananaMCP	mcp-nanobanana-pro	Image	Documentation
producer/	ProducerMCP	mcp-producer	Music	Documentation
seedance/	SeedanceMCP	mcp-seedance	Video	Documentation
qwen-image/	QwenImageMCP	mcp-qwen-image	Image	Documentation
seedream/	SeedreamMCP	mcp-seedream-pro	Image	Documentation
serp/	SerpMCP	mcp-serp	Search	Documentation
shorturl/	ShortURLMCP	mcp-shorturl	Utility	Documentation
suno/	SunoMCP	mcp-suno	Music	Documentation
veo/	VeoMCP	mcp-veo	Video	Documentation
wan/	WanMCP	mcp-wan	Video	Documentation
aichat/	AiChatMCP	mcp-aichat	Chat	Documentation
digitalhuman/	DigitalHumanMCP	mcp-digitalhuman	Video	Documentation
hcaptcha/	HCaptchaMCP	mcp-hcaptcha	CAPTCHA	Service details
image2text/	Image2TextMCP	mcp-image2text	OCR	Service details
recaptcha/	RecaptchaMCP	mcp-recaptcha	CAPTCHA	Service details
turnstile/	TurnstileMCP	mcp-turnstile	CAPTCHA	Documentation
discord-bot/	DiscordBotMCP	mcp-discord-bot	Messaging	Documentation
glm/	GLMMCP	mcp-glm	Chat	Documentation
grok/	GrokMCP	mcp-grok	Video	Documentation
minimax/	MinimaxMCP	mcp-minimax	Video	Documentation
openai/	OpenAIMCP	mcp-openai-pro	AI APIs	Documentation
webextrator/	WebExtratorMCP	mcp-webextrator	Web & Data	Documentation

Connect to a server

Each active package README now starts with its actual connection choices. For the verified hosted servers, add the HTTPS MCP URL and use your client's OAuth flow, or use an API credential only when an explicit Bearer header is needed. Local stdio packages need an API credential even though the server process runs on your machine. Suno shows the full music-generation flow; other READMEs use their own endpoint and tool names.

Two exceptions matter: AceDataCloudMCP manages the account and uses a platform token, while DiscordBotMCP connects to a user's deployed Discord Agent Proxy and uses that proxy's URL and token. Five packages—Digital Human, hCaptcha, Image2Text, reCAPTCHA and Turnstile—currently document local setup because their public hosted HTTPS endpoints could not be verified. Sora remains retired.

Obtain the right credential

For generation/search API keys, follow the illustrated application-key steps: register or sign in, initialize General application if needed, open Keys / Manage Keys, create or copy a key, then store it in your client. Check service access, limits and balance before your first request.

The account-management server uses Account Tokens instead; see its creation steps. Hosted OAuth users follow browser sign-in instead of copying a key. The Discord Agent Proxy uses the URL and token issued by that deployment, as explained in its prerequisites.

Retired

Directory	Standalone Repo	PyPI Package	Status
sora/	SoraMCP	mcp-sora	Retired; retained for historical reference

Service discovery in the official MCP Registry

Suno, Seedance, HappyHorse and Nano Banana keep their existing independent Registry entries and packages. Display titles identify them as integrations by Ace Data Cloud; namespace and package identities remain stable. The canonical scripts/mcp_catalog.json supplies Registry titles, descriptions, icons and profile metadata. Run python3 -m scripts.registry_metadata --check to check the projection, or omit --check to refresh it. Website destinations use the existing documentation catalog and current marketing link contract.

GPT Image has a separate image-only profile in the existing openai/ source: openai/GPT_IMAGE.md. Its published mcp-gpt-image manifest selects mcp-openai-pro --profile gpt-image and exposes five image/task tools, excluding the general OpenAI tool set and remote. The official io.github.AceDataCloud/mcp-gpt-image listing and matching mcp-openai-pro package were read back at version 2026.10.18.2 on 2026-10-19. The profile reuses maintained image/task code rather than duplicating a provider implementation or renaming the general server.

The official Registry is a metadata directory, not a default LLM provider selector. Its current search matches server names; a display title does not add spaced search aliases. Downstream catalogs may render titles/icons and provide richer search, but their ingestion and actual client installation must be checked separately.

Runtime initialize.serverInfo.icons is a separate projection. Only catalog entries with runtime_icon opt in: "registry" reuses that service's canonical Registry asset, while an explicit icon supports a generic server without borrowing a profile's identity. Run python3 -m scripts.runtime_metadata (--check checks drift) and commit the generated core/server.py icon edits. This changes neither server names/tools nor Registry manifests, Smithery server cards or listing metadata. Valid protocol metadata does not prove that a client has fetched or rendered the image.

Publishing

The combined Ace Data Cloud MCP extension is maintained in vscode-bundle/. sync.yaml distributes that source to VSCodeMCP, whose publish workflow builds and verifies the Marketplace release. Individual service extensions remain independent.

Enable a verified hosted service through vscode_bundle in scripts/mcp_catalog.json, then run python3 scripts/build_vscode_bundle.py. The generator reads hosted URLs and credential kinds from each server.json; it excludes retired services and rejects unexpected credential destinations. Normal CI checks the generated service list and runs the bundle's tests/package build. Update the source here rather than editing the standalone repository.

Each MCP is published to multiple channels automatically on every push to main:

Channel	Status
PyPI	Active servers published
VS Code Marketplace	Active extensions published
JetBrains Marketplace	Per-plugin upload and approval; source sync does not imply public availability
Smithery	Existing URL publishers verify each accepted release; listing and installation require separate checks
MCP Registry	Active servers published

Smithery CLI returns a pending receipt in CI. Existing Smithery publishing jobs wait for that exact release to reach SUCCESS; failure, authorization required, and timeout fail the job. Keep shared/smithery_release.py and the standalone distribution copies in sync with python3 scripts/sync_smithery_release.py (--check verifies them). A successful release does not prove a new user can install, authorize, or complete a paid tool call.

Versioning uses CalVer (YYYY.M.D.BUILD), auto-generated at publish time.

How It Works

Sync Pipeline

PlatformBackend's daily ecosystem CronJob prepares incremental capability PRs using a pinned Backend source. Existing CI and human review gate each update. The previous dispatch/Copilot sync workflows are retired.

After a reviewed PR lands, sync-to-repos.yml distributes the affected packages to their standalone repositories for publishing.

Rules

• This monorepo is the source of truth. Do not edit standalone repos directly.
• The mapping between subdirectories and standalone repos is defined in sync.yaml.
• CI runs lint (ruff) and tests (pytest, Python 3.10/3.11/3.12) on every push and PR.

Development

Shared OAuth

The 28 servers listed in scripts/sync_oauth.py maintain their identical OAuth implementation in shared/oauth.py. Edit that source, then run:

python3 scripts/sync_oauth.py
python3 scripts/sync_oauth.py --check
python3 -m unittest scripts.test_sync_oauth -v

Commit the generated core/oauth.py copies together with the shared-source change. CI rejects stale or manually changed copies; these per-server changes also trigger the existing test, build, and standalone-repository sync matrices. The copies are distribution artifacts: each server still runs and builds from its own directory, with no new dependency or shared service to deploy.

acedatacloud keeps its PlatformToken flow. digitalhuman and happyhorse keep their additional redirect validation and revoked-token tracking. midjourney keeps its distinct callback/token-exchange implementation. Their local files are never generated; the sync script requires every OAuth server to be classified explicitly before writing any copies.

Hosted OAuth requests use canonical AuthBackend scopes: API-credential servers request profile:read, applications:read, applications:write, credentials:read, and credentials:write. The account-management server requests the account scopes documented in its authorization table, covering the tools as well as platform-token issuance. Its trusted OAuth application must be synced by AuthBackend before rollout.

To run shared OAuth behavior tests, install ./suno[test] in an isolated Python environment (as the representative self-contained package), then run python -m pytest shared/test_oauth.py from the repository root. Tests mock all HTTP calls and do not require account credentials.

Server development

cd <server>/
pip install -e ".[dev]"
pytest --cov=core --cov=tools
ruff check .

Test discovery

Run pytest for shared behavior tests and python3 -m unittest for repository tooling tests. CI discovers both directories; new tests need no workflow edits. Each MCP package keeps its existing pytest test-discovery configuration.

Marketing links

The shared key-creation steps live in scripts/token_onboarding.py; marked sections are refreshed for each distribution channel, including the VS Code bundle. The same guide is rendered into each JetBrains plugin.xml description because Marketplace displays that descriptor rather than the repository README. Edit the surrounding package tutorial in README.md, then run python3 scripts/marketing_readmes.py. The same source generates README.pypi.md; the package metadata selects that file. All active entries in scripts/mcp_catalog.json participate, including available VS Code and JetBrains READMEs. Sora remains retired. Code examples and MCP/API protocol URLs are not marketing links and remain unchanged.

Channel rules come from the links projection of the single PlatformBackend/config/marketing_attribution.json source. Refresh that generated snapshot using PlatformBackend's scripts/export_marketing_contract.py --consumer mcps --target /path/to/MCPs. Service destinations stay in the existing MCP catalog. A new service needs no AuthBackend, frontend or global-contract edit.

Tags use source github, pypi, vscode_marketplace or jetbrains_marketplace, medium referral, campaign evergreen, and content <service>_mcp_<readme|package|vscode|jetbrains>_<placement>. A marketplace README identifies its distribution artifact; UTM labels are not verified HTTP referrers. CI's discovered unittest suite rejects stale generated files, wrong channels, and missing package README inclusion. python3 scripts/marketing_readmes.py --check can also be run directly. Package publication follows the existing release workflow.

Daily capability updates

PlatformBackend ecosystem.py is the only scheduled coordinator. One daily Kubernetes Job reviews Backend docs and API changes with Claude Code, updates existing files, and creates or updates one reviewable PR per repository. It never merges PRs or duplicates the Backend guide tree. Normal CI and review remain required; publication and sub-repository mirroring run after merge.