Monorepo for all AceDataCloud MCP (Model Context Protocol) servers.
| 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 dispatches platform-contracts-updated with an exact source
commit. sync-from-platformbackend.yml compiles and verifies that contract,
resolves affected package directories, and opens a scoped parity issue. Custom
tool adapters are updated in a normal PR with the existing CI and review gates.
There is no second Docs-triggered code sync, PR cleanup, polling job, or admin
merge. Published Docs remain a reference for users.
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.
Edit each package's 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.