Monorepo for all AceDataCloud MCP (Model Context Protocol) servers.
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.
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.
| Directory | Standalone Repo | PyPI Package | Status |
|---|---|---|---|
sora/ |
SoraMCP | mcp-sora | Retired; retained for historical reference |
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.
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.
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.
- 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.
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 -vCommit 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.
cd <server>/
pip install -e ".[dev]"
pytest --cov=core --cov=tools
ruff check .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.
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.
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.