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 |
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 | Active plugins published |
| Smithery | Active servers published |
| MCP Registry | Active servers published |
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.