{"id":"0a93331f-ebf1-4eb1-92ed-0374a02eb620","entityType":"agent","slug":"clawhub-loonghao-dcc-mcp-creator","name":"DCC-MCP Creator","canonicalUrl":"https://www.xpersona.co/agent/clawhub-loonghao-dcc-mcp-creator","canonicalPath":"/agent/clawhub-loonghao-dcc-mcp-creator","generatedAt":"2026-10-09T16:20:07.394Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:27:04.696Z","emptyReason":null},"description":"Create and modernize DCC-MCP adapters","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 6.3K downloads reported by the source. Last updated 10/9/2026.","installCommand":"clawhub skill install s176cy7je3jzfnkewtyz7ja0e183m3t9:dcc-mcp-creator","sourceUrl":"https://clawhub.ai/loonghao/dcc-mcp-creator","homepage":"https://clawhub.ai/loonghao/skills/dcc-mcp-creator","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/loonghao/dcc-mcp-creator","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/loonghao/skills/dcc-mcp-creator","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":76,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"DCC-MCP Creator technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:27:04.696Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:27:04.696Z","emptyReason":null},"stars":null,"forks":null,"downloads":6264,"packageName":null,"latestVersion":"0.19.107","tractionLabel":"6.3K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:27:04.696Z","emptyReason":null},"lastUpdatedAt":"2026-10-09T03:27:04.696Z","lastCrawledAt":"2026-10-09T03:27:04.696Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-10T03:27:04.696Z","lastVerifiedAt":null,"highlights":[{"version":"0.19.107","createdAt":"2026-09-29T15:26:49.044Z","changelog":"- Updated version to 0.19.107. - Documentation updates in SKILL.md and reference files. - Removed skill-card.md for cleanup. - No changes to core functionality or implementation boundaries.","fileCount":13,"zipByteSize":34642},{"version":"0.19.106","createdAt":"2026-09-14T07:38:20.222Z","changelog":"- Version bump: Updated internal version to 0.19.106. - Documentation update: SKILL.md updated to reflect new version. - File cleanup: Removed obsolete skill-card.md file.","fileCount":13,"zipByteSize":34705},{"version":"0.19.105","createdAt":"2026-09-13T15:49:22.553Z","changelog":"- Bumped internal version metadata to 0.19.105 in SKILL.md. - No other content or functional changes.","fileCount":13,"zipByteSize":34654},{"version":"0.19.104","createdAt":"2026-09-13T15:45:07.887Z","changelog":"**Summary: Major update with expanded reference docs, clarified implementation boundaries, and streamlined guidance.** - Added new reference documents: FAILURE_ROUTING.md, INTEGRATION_EXAMPLES.md, RUNTIME_INTEGRATION.md. - Removed skill-card.md and condensed SKILL.md with clearer explanations of scope, implementation, and non-negotiables. - Clarified boundaries for public vs. private/internal service use. - Improved guidance section with a quick-reference table linking key workflows to relevant docs. - Emphasized separation of validation responsibilities, adapter-core boundaries, and privacy requirements.","fileCount":13,"zipByteSize":34999},{"version":"0.19.103","createdAt":"2026-09-10T08:12:32.782Z","changelog":"dcc-mcp-creator v0.19.103 - Updated internal version to 0.19.103 in SKILL.md metadata. - Removed redundant skill-card.md file. - No functional workflow or usage changes.","fileCount":10,"zipByteSize":32535},{"version":"0.19.102","createdAt":"2026-09-10T05:37:32.090Z","changelog":"- Version bumped to 0.19.102 in metadata. - Removed obsolete file: skill-card.md. - No functional changes; documentation and metadata update only.","fileCount":10,"zipByteSize":32620},{"version":"0.19.101","createdAt":"2026-09-09T15:37:00.014Z","changelog":"dcc-mcp-creator 0.19.101 - Updated internal version to 0.19.101 in metadata. - Added new reference document: references/ASYNC_RECOVERY.md. - Removed deprecated skill-card.md file. - Minor internal documentation and reference list maintenance.","fileCount":10,"zipByteSize":32696},{"version":"0.19.100","createdAt":"2026-09-07T12:12:08.755Z","changelog":"dcc-mcp-creator 0.19.100 - Updated version to 0.19.100 in metadata for compatibility tracking. - Documentation updates in SKILL.md and references, including improved clarity and updated references. - Removed obsolete file: skill-card.md. - No changes to skill functionality or CLI; this is a documentation and metadata maintenance release.","fileCount":9,"zipByteSize":31748}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s176cy7je3jzfnkewtyz7ja0e183m3t9:dcc-mcp-creator","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s176cy7je3jzfnkewtyz7ja0e183m3t9:dcc-mcp-creator` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/loonghao/dcc-mcp-creator before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-creator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-creator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-creator/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-creator/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-creator/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-creator/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-09T16:20:07.390Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-creator/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-creator/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-creator/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-loonghao-dcc-mcp-creator/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-09T03:27:04.696Z","emptyReason":null},"readme":"Skill: DCC-MCP Creator\n\nOwner: loonghao\n\nSummary: Create and modernize DCC-MCP adapters\n\nTags: latest:0.19.107\n\nVersion history:\n\nv0.19.107 | 2026-09-29T15:26:49.044Z | auto\n\n- Updated version to 0.19.107.\n- Documentation updates in SKILL.md and reference files.\n- Removed skill-card.md for cleanup.\n- No changes to core functionality or implementation boundaries.\n\nv0.19.106 | 2026-09-14T07:38:20.222Z | auto\n\n- Version bump: Updated internal version to 0.19.106.\n- Documentation update: SKILL.md updated to reflect new version.\n- File cleanup: Removed obsolete skill-card.md file.\n\nv0.19.105 | 2026-09-13T15:49:22.553Z | auto\n\n- Bumped internal version metadata to 0.19.105 in SKILL.md.\n- No other content or functional changes.\n\nv0.19.104 | 2026-09-13T15:45:07.887Z | auto\n\n**Summary: Major update with expanded reference docs, clarified implementation boundaries, and streamlined guidance.**\n\n- Added new reference documents: FAILURE_ROUTING.md, INTEGRATION_EXAMPLES.md, RUNTIME_INTEGRATION.md.\n- Removed skill-card.md and condensed SKILL.md with clearer explanations of scope, implementation, and non-negotiables.\n- Clarified boundaries for public vs. private/internal service use.\n- Improved guidance section with a quick-reference table linking key workflows to relevant docs.\n- Emphasized separation of validation responsibilities, adapter-core boundaries, and privacy requirements.\n\nv0.19.103 | 2026-09-10T08:12:32.782Z | auto\n\ndcc-mcp-creator v0.19.103\n\n- Updated internal version to 0.19.103 in SKILL.md metadata.\n- Removed redundant skill-card.md file.\n- No functional workflow or usage changes.\n\nv0.19.102 | 2026-09-10T05:37:32.090Z | auto\n\n- Version bumped to 0.19.102 in metadata.\n- Removed obsolete file: skill-card.md.\n- No functional changes; documentation and metadata update only.\n\nv0.19.101 | 2026-09-09T15:37:00.014Z | auto\n\ndcc-mcp-creator 0.19.101\n\n- Updated internal version to 0.19.101 in metadata.\n- Added new reference document: references/ASYNC_RECOVERY.md.\n- Removed deprecated skill-card.md file.\n- Minor internal documentation and reference list maintenance.\n\nv0.19.100 | 2026-09-07T12:12:08.755Z | auto\n\ndcc-mcp-creator 0.19.100\n\n- Updated version to 0.19.100 in metadata for compatibility tracking.\n- Documentation updates in SKILL.md and references, including improved clarity and updated references.\n- Removed obsolete file: skill-card.md.\n- No changes to skill functionality or CLI; this is a documentation and metadata maintenance release.\n\nv0.19.99 | 2026-09-06T07:27:21.517Z | auto\n\n- Bumped skill version to 0.19.99.\n- Updated metadata version to reflect the new release.\n- Removed the `skill-card.md` file.\n- No changes to functionality or external interface.\n\nv0.19.98 | 2026-09-04T13:46:21.869Z | auto\n\ndcc-mcp-creator 0.19.98\n\n- Updated SKILL.md to version 0.19.98 (metadata version bump from 0.19.97).\n- Removed redundant file: skill-card.md.\n- No functional or workflow changes; documentation and housekeeping only.\n\nv0.19.97 | 2026-09-03T15:54:42.128Z | auto\n\ndcc-mcp-creator v0.19.97\n\n- Updated compatibility metadata to v0.19.97.\n- Improved CLI update and verification flow: now requires official update manifests and Sigstore provenance for CLI updates; legacy unsigned staging is quarantined.\n- Added clarifications regarding pip install metadata requirements for public adapters (exact HTTPS URL, catalog version, SHA-256).\n- Documented the adapter-owned install, status, verify, uninstall, and upgrade contract (see new reference to adapter-install-sop).\n- Removed deprecated skill-card.md file.\n- Multiple documentation refinements and policy clarifications across reference docs.\n\nv0.19.92 | 2026-08-06T03:18:34.553Z | auto\n\n- Updated skill version to 0.19.92 in metadata.\n- Changed the Openclaw homepage URL in metadata to point to the correct repository path.\n- Removed the outdated skill-card.md file.\n\nv0.19.91 | 2026-08-04T13:18:35.440Z | auto\n\n- Bumped version to 0.19.91 in SKILL.md metadata.\n- Removed obsolete skill-card.md file.\n- No functional or documentation changes to core guidance or workflows.\n\nv0.19.90 | 2026-07-31T15:25:20.712Z | auto\n\n- Version bumped to 0.19.90.\n- Updated version metadata in SKILL.md.\n- Removed redundant skill-card.md file.\n\nv0.19.89 | 2026-07-31T07:22:08.435Z | auto\n\n- Bumped version to 0.19.89.\n- Removed the file: skill-card.md.\n- SKILL.md metadata updated to reflect new version.\n- No functional changes to core logic; documentation and package metadata only.\n\nv0.19.88 | 2026-07-31T03:36:54.242Z | auto\n\n- Added support and documentation for creating standalone internal MCP services and private non-DCC integrations.\n- Introduced the new reference: INTERNAL_SERVICE_WORKFLOW.md.\n- Updated SKILL.md with guidance for both public DCC adapters and private/internal service use cases.\n- Skill reference tags and search hints expanded for standalone/internal service support.\n- Removed outdated skill-card.md.\n- Clarified that a public repository is not required for private/internal service projects.\n\nv0.19.87 | 2026-07-30T02:15:58.791Z | auto\n\n- Version updated to 0.19.87.\n- Internal metadata version bump in SKILL.md.\n- Removed file: skill-card.md.\n- No user-facing feature changes.\n\nv0.19.86 | 2026-07-29T02:19:22.020Z | auto\n\n- Added installation instructions for the `dcc-mcp-creator` skill package and related commands.\n- Clarified usage boundaries between `dcc-mcp-creator`, `dcc-mcp`, and `dcc-mcp-skills-creator`.\n- Updated metadata version to 0.19.86.\n- Removed the unused or redundant `skill-card.md` file.\n\nv0.19.85 | 2026-07-28T18:02:10.743Z | auto\n\n- Bumped skill version to 0.19.85.\n- Removed the file: skill-card.md.\n- SKILL.md updated to reference new version and streamline metadata.\n\nv0.19.84 | 2026-07-28T08:47:33.514Z | auto\n\n- Bumped internal version to 0.19.84 in metadata.\n- Updated reference and release documentation.\n- Removed the obsolete skill-card.md file.\n\nv0.19.83 | 2026-07-27T18:03:18.191Z | auto\n\n- Version bump to 0.19.83.\n- Documentation updated in SKILL.md and references/TESTING_AND_RELEASE.md.\n- Removed obsolete file: skill-card.md.\n\nv0.19.82 | 2026-07-27T00:19:06.800Z | auto\n\n- Version bumped to 0.19.82.\n- Removed redundant skill-card.md file.\n- No changes to functional logic; documentation and metadata only.\n\nv0.19.81 | 2026-07-26T22:07:31.347Z | auto\n\n- Incremented skill version to 0.19.81.\n- Removed unused or deprecated file: skill-card.md.\n- Minor update to SKILL.md to reflect the new version.\n\nv0.19.80 | 2026-07-26T17:52:44.130Z | auto\n\n- Version bumped to 0.19.80.\n- Outdated \"skill-card.md\" file removed.\n- Documentation in SKILL.md updated to reflect new version.\n- No changes to core functionality.\n\nv0.19.79 | 2026-07-26T13:40:04.900Z | auto\n\n- Version bump to 0.19.79.\n- Updated internal version string in SKILL.md.\n- Removed redundant skill-card.md file.\n- No other changes to workflow or documentation content.\n\nv0.19.78 | 2026-07-26T04:40:24.793Z | auto\n\n- Version bumped to 0.19.78.\n- Documentation update in SKILL.md (version metadata updated).\n- Removed the redundant skill-card.md file.\n\nv0.19.77 | 2026-07-25T08:52:56.839Z | auto\n\n- Bumped skill version to 0.19.77.\n- Updated `SKILL.md` metadata to reflect new version.\n- Removed redundant file `skill-card.md`.\n\nv0.19.76 | 2026-07-25T05:51:24.707Z | auto\n\n- Bumped skill version to 0.19.76.\n- Removed the obsolete skill-card.md file.\n- Updated SKILL.md to reflect the new version and maintain current references. \n- No functional changes to skill logic or workflow documented.\n\nv0.19.75 | 2026-07-24T23:18:50.724Z | auto\n\n- Bumped version to 0.19.75.\n- Removed obsolete skill-card.md file to streamline documentation.\n- SKILL.md was updated to reflect the new version and maintain accurate metadata.\n- No changes to core functionality or usage instructions.\n\nv0.19.74 | 2026-07-24T20:09:57.932Z | auto\n\n- Bumped version to 0.19.74.\n- Updated version metadata in SKILL.md.\n- Removed the skill-card.md file.\n\nv0.19.73 | 2026-07-24T08:07:01.828Z | auto\n\n- Bumped version to 0.19.73.\n- Removed the file: skill-card.md.\n- Updated SKILL.md metadata to reflect new version.\n- No functional logic changes; primarily maintenance and cleanup.\n\nv0.19.72 | 2026-07-23T22:26:37.326Z | auto\n\n- Version bumped to 0.19.72.\n- Internal documentation updated in SKILL.md (version metadata).\n- Removed redundant or outdated skill-card.md file.\n\nv0.19.71 | 2026-07-23T18:55:47.089Z | auto\n\ndcc-mcp-creator 0.19.71\n\n- Updated version metadata to 0.19.71.\n- Improved SKILL.md documentation: clarified UI control usage, chunked main-thread jobs, and cooperative cancellation features.\n- Enhanced search-hint and tags in metadata for more accurate discovery.\n- Removed outdated skill-card.md file.\n\nv0.19.64 | 2026-07-21T22:41:16.148Z | auto\n\n- Expanded documentation and workflow guidance for creating or modernizing DCC-MCP adapters, including detailed runtime vocabulary and host integration classifications.\n- Emphasized best practices for adapter lifetime management, host API routing, and DCC identity configuration to ensure data-driven integration.\n- Clarified usage of skill discovery, marketplace install paths, and hermetic test settings for adapter developers.\n- Added explicit step-by-step fast workflow and cross-references to relevant reference and policy documentation.\n- Updated compatibility policy: maintains explicit Python 3.7 LTS support and outlines deprecation procedures.\n- Reinforced guidance against duplicating platform conventions or writing adapter-local wrappers for skills covered by core utilities.\n\nv0.19.63 | 2026-07-21T17:35:04.223Z | auto\n\n- Initial release of dcc-mcp-creator v0.19.63 with comprehensive guidance for building and modernizing DCC-MCP adapters.\n- Covers workflows and integration patterns for Nuke, Blender, 3ds Max, Unreal, ZBrush, Houdini, Maya, and custom DCC tools.\n- Provides detailed modern reference on server/sidecar/gateway architecture, lifecycle, and CLI-first control path.\n- Enforces best practices for Python 3.7+ compatibility and adapter skill/path handling.\n- Includes documentation pointers for onboarding, compatibility, release, and host integration.\n\nv0.19.62 | 2026-07-20T07:21:27.658Z | auto\n\n- Overhauled SKILL.md with comprehensive developer and agent guidance for creating or updating DCC-MCP adapters across multiple DCC platforms.\n- Clarified use cases, host types, and adapter workflows, emphasizing best practices for server, dispatcher, and gateway integration.\n- Expanded documentation references for onboarding, lifecycle management, and compatibility.\n- Updated vocabulary and policy notes, including Python 3.7 support and adapter discovery practices.\n- Added detailed fast workflow checklist for consistent adapter development and validation.\n\nv0.19.61 | 2026-07-20T05:12:05.012Z | auto\n\n- Added detailed guidance and vocabulary for creating or modernizing full DCC-MCP adapters for DCCs such as Nuke, Blender, 3ds Max, Unreal, ZBrush, Houdini, Maya, and custom tools.\n- Clarified distinction between infrastructure skill (this package) and individual skill package authoring (`dcc-mcp-skills-creator`).\n- Expanded usage instructions with explicit workflow steps, CLI-based control path, and core policy notes (e.g., Python 3.7 requirements).\n- Documented fast workflow for classification, integration, and testing of new adapters.\n- Updated references to official documentation for onboarding, gateway lifecycle, install lifecycle, and compatibility matrix.\n- Established best practices for host API routing, skill discovery, Windows UI integration, and raw input handling.\n\nv0.19.60 | 2026-07-19T19:10:16.731Z | auto\n\n- Expanded and clarified documentation in SKILL.md, providing comprehensive workflow instructions for creating or modernizing DCC-MCP adapters.\n- Added detailed runtime vocabulary definitions for key infrastructure components (e.g., sidecar, gateway daemon, guardian).\n- Updated fast workflow guidance, including adapter classification and host integration best practices.\n- Specified compatibility requirements: dcc-mcp-core 0.17+ and Python 3.7+ (with LTS policy details).\n- Included explicit guidelines for skill discovery, marketplace integration, and Windows UI fallback procedures.\n- Enhanced onboarding references and linked to relevant documentation for adapter build, testing, release, and compatibility.\n\nv0.19.59 | 2026-07-19T01:23:52.102Z | auto\n\n- Updated documentation in SKILL.md to provide comprehensive guidance on creating or modernizing DCC-MCP adapters for various DCC applications.\n- Clarified adapter development workflow, including host integration classification and key reference documentation.\n- Expanded runtime vocabulary and fast workflow instructions for adapter development.\n- Emphasized usage of core helpers, structured skill discovery, and integration best practices.\n- Documented Python 3.7 support policy and release compliance requirements.\n\nv0.19.58 | 2026-07-18T20:10:56.680Z | auto\n\n- Added detailed guidance and definitions for creating or modernizing DCC-MCP adapters covering server composition, host-thread dispatch, sidecar/gateway wiring, and integration workflows.\n- Expanded runtime vocabulary, including key concepts: DCC startup hook, Per-DCC service, Sidecar, Gateway daemon, Guardian, and Service heartbeat.\n- Outlined a step-by-step fast workflow for classifying host types, reading core references, starting from recommended codebases, and enforcing core integration patterns.\n- Updated policies on Python 3.7 support, skill discovery conventions, and marketplace integration for streamlined testing and compliance.\n- Provided clear guidance on Windows UI integration, raw input handling, and safe practices for agent-directed automation in DCC environments.\n- Added best practices for CLI usage, gateway modes, adapter configuration, and lifecycle management with references to upstream documentation.\n\nv0.19.57 | 2026-07-18T18:43:28.031Z | auto\n\n- Added comprehensive SKILL.md with detailed guidance on creating and modernizing DCC-MCP adapters for host applications like Nuke, Blender, 3ds Max, Unreal, ZBrush, Houdini, and Maya.\n- Defined key infrastructure concepts, runtime vocabulary, and clarified tooling boundaries between dcc-mcp-creator and dcc-mcp-skills-creator.\n- Documented a step-by-step fast workflow, including best practices for adapter structure, host API routing, per-DCC service, sidecar management, gateway integration, and skill discovery.\n- Included policy notes on Python 3.7 support and adapter compatibility checks.\n- Extended guidance for specialized cases like visual UI fallback, raw input coordination, and responsible use of destructive operations.\n- Linked all core and adapter-related documentation references to support consistent, policy-compliant development.\n\nv0.19.56 | 2026-07-18T07:22:47.974Z | auto\n\n- Added detailed SKILL.md with comprehensive guidance for creating and modernizing DCC-MCP adapters for tools like Nuke, Blender, 3ds Max, Unreal, ZBrush, Houdini, and Maya.\n- Documented infrastructure concepts: server, dispatcher, gateway, sidecar, readiness, and resource management.\n- Provided step-by-step fast workflow, including host integration classification and adapter wiring best practices.\n- Included runtime vocabulary for essential terms and adapter lifecycle policies, emphasizing Python 3.7 compatibility and adapter installation guidance.\n- Clarified skill usage boundaries and integration points with other dcc-mcp skills.\n\nv0.19.55 | 2026-07-17T20:46:13.397Z | auto\n\n- Added comprehensive SKILL.md documentation with detailed workflows and vocabulary for creating or modernizing full DCC-MCP adapters.\n- Clarified compatibility: supports dcc-mcp-core 0.17+ and Python 3.7+ with long-term support policy.\n- Outlined fast workflow steps for host integration, reference guides, and best practices for adapter development.\n- Provided strict guidelines for handling DCC identity, skill discovery paths, sidecar/gateway management, and UI control.\n- Specified adapter usage boundaries; individual skill package authoring should use dcc-mcp-skills-creator.\n\nv0.19.54 | 2026-07-17T19:15:12.053Z | auto\n\n- Added comprehensive guidance and workflow documentation for creating or modernizing DCC-MCP adapters across multiple DCCs (Nuke, Blender, 3ds Max, Unreal, ZBrush, Houdini, Maya, and custom tools).\n- Clarified core concepts, including host integration types, sidecar usage, gateway daemon, and service heartbeat.\n- Documented adapter compatibility, Python 3.7 LTS support policies, skill discovery paths, and integration with marketplace-installed skills.\n- Provided detailed instructions on proper usage of host APIs, `HostExecutionBridge`, and integration with the `app-ui` skill, including Windows-specific workflows for raw input and process coordination.\n- Added references and checklists for adapter development, host pattern matrix, testing, release, onboarding, and lifecycle management.\n\nv0.19.53 | 2026-07-17T18:03:22.191Z | auto\n\n- Initial release of the dcc-mcp-creator infrastructure skill, version 0.19.53.\n- Guides developers through building or modernizing DCC-MCP adapters for a range of DCC tools including Nuke, Blender, 3ds Max, Unreal, ZBrush, Houdini, Maya, and custom studio tools.\n- Includes detailed runtime vocabulary and workflow best practices for adapter/server composition and host integration.\n- References and enforces Python 3.7+ compatibility with specific release and testing guidelines.\n- Outlines core integration patterns, correct usage of sidecars, gateways, heartbeats, and install lifecycle.\n- Clearly differentiates adapter infrastructure work from individual SKILL package authoring (use dcc-mcp-skills-creator for the latter).\n\nv0.19.52 | 2026-07-17T12:16:11.542Z | auto\n\n- Added a detailed SKILL.md outlining usage, terminology, fast workflow, and best practices for adapter development and modernization.\n- Clarified when to use dcc-mcp-creator versus dcc-mcp-skills-creator, including adapter versus individual skill package scenarios.\n- Provided in-depth runtime vocabulary for core concepts: startup hook, per-DCC service, sidecar, gateway daemon, guardian, and service heartbeat.\n- Documented actionable workflow steps for building, wiring, and managing DCC-MCP adapters, including process isolation, skill search paths, and test scenarios.\n- Explained Windows visual UI workflows and strict requirements for app-ui integration and raw input policy.\n- Listed and referenced important adapter lifecycle and gatekeeping documentation for improved compliance and onboarding.\n\nv0.19.51 | 2026-07-17T09:44:19.874Z | auto\n\n- Adds comprehensive documentation in SKILL.md for creating and modernizing DCC-MCP adapters, including workflow steps, terminology, and best practices.\n- Updates compatibility and usage guidance for DCC-MCP and associated tools.\n- Details adapter requirements for multiple DCCs like Nuke, Blender, 3ds Max, Unreal, ZBrush, Houdini, Maya, and custom tools.\n- Outlines explicit policies for Python 3.7 support and adapter test setup.\n- Provides clear structured instructions for adapter developers and agents.\n\nv0.19.50 | 2026-07-17T05:35:17.156Z | auto\n\n- Expanded and detailed documentation in SKILL.md to guide developers on creating or modernizing a DCC-MCP adapter for multiple DCC applications.\n- Clarified the distinction between infrastructure adapter creation (this skill) and individual skill package authoring (use dcc-mcp-skills-creator instead).\n- Added detailed vocabulary and role descriptions for key adapter concepts, including sidecar, gateway daemon, service heartbeat, and guardian.\n- Provided comprehensive step-by-step workflow covering host integration types, setup, core references, best practices, and UI/automation integration policies.\n- Included up-to-date compatibility information and a strong policy statement on Python 3.7 LTS support and release gate requirements.\n\nv0.19.49 | 2026-07-17T04:34:14.504Z | auto\n\n- Updated documentation in SKILL.md for clearer guidance on creating or modernizing DCC-MCP adapters across multiple DCCs.\n- Expanded reference and workflow sections, including detailed step-by-step instructions and additional policy notes (e.g., Python 3.7 LTS requirements).\n- Clarified adapter integration, host classification, and gateway/sidecar processes.\n- Added comprehensive runtime vocabulary and fast workflow checklists to support adapter developers.\n- Refined best practices around skill discovery, Windows UI fallback, and agent/operator input handling.\n\nv0.19.48 | 2026-07-17T02:17:33.766Z | auto\n\n- Expanded and clarified guidance for creating and modernizing DCC-MCP adapters, covering server composition, dispatch, gateway wiring, and runtime integration across major DCC hosts.\n- Added detailed runtime terminology for concepts like sidecar, gateway daemon, guardian, and service heartbeat.\n- Updated fast workflow with explicit references to new and existing documentation, compatibility rules, and best practices for adapter development and release.\n- Reinforced Python 3.7 LTS support policy and provided stricter requirements for deprecating Python 3.7.\n- Clarified usage patterns for launching and supervising sidecars, handling instance identities, and registry integration for diverse deployment scenarios.\n- Addressed test isolation, CLI usage conventions, and adapter compatibility matrix referencing.\n\nArchive index:\n\nArchive v0.19.107: 13 files, 34642 bytes\n\nFiles: agents/openai.yaml (220b), references/ADAPTER_WORKFLOW.md (6852b), references/ASYNC_RECOVERY.md (6321b), references/CORE_ESCALATION_CHECKLIST.md (3026b), references/FAILURE_ROUTING.md (2218b), references/HOST_PATTERN_MATRIX.md (4375b), references/INTEGRATION_EXAMPLES.md (2700b), references/INTERNAL_SERVICE_WORKFLOW.md (6149b), references/RUNTIME_INTEGRATION.md (25433b), references/TESTING_AND_RELEASE.md (6429b), skill-card.md (2102b), SKILL.md (4430b), _meta.json (137b)\n\nFile v0.19.107:SKILL.md\n\n---\nname: dcc-mcp-creator\ndescription: >-\n  Build or modernize DCC-MCP adapters and standalone studio MCP services. For individual tool skill packages, use dcc-mcp-skills-creator.\nlicense: MIT-0\nallowed-tools: Bash Read Write Edit\nmetadata:\n  dcc-mcp:\n    dcc: python\n    layer: infrastructure\n    compatibility: \"dcc-mcp-core 0.17+, Python 3.7+\"\n    version: \"0.19.107\"\n    search-hint: >-\n      create DCC MCP adapter, Nuke MCP, DccServerBase, HostExecutionBridge,\n      dispatcher, readiness, resources, gateway, Blender, 3ds Max, Unreal,\n      ZBrush, Houdini, Maya, standalone internal MCP service, private intranet,\n      non-DCC server, chunked main-thread jobs, cooperative cancellation\n    tags: \"adapter-development, internal-mcp-service, standalone, host-runtime, dispatcher, gateway, nuke, blender, 3dsmax, unreal, zbrush\"\n    skill-reference-docs:\n      - \"references/*.md\"\n  openclaw:\n    homepage: https://github.com/dcc-mcp/dcc-mcp-agent-plugins/blob/main/plugins/dcc-mcp/skills/dcc-mcp-creator/SKILL.md\n---\n\n# DCC-MCP Creator\n\nImplement the requested adapter or service within its owner's project. A private\nservice needs no public repository, catalog entry, issue or release. For operating\nan existing app use `dcc-mcp`; for individual tool packages use `dcc-mcp-skills-creator`.\nAn already-loaded skill needs no installation or new agent turn.\n\n## Implementation boundaries\n\nUse `DccServerBase` and `DccServerOptions.from_env(...)`, with host API calls\nthrough `HostExecutionBridge`. Embedded, sidecar and standalone services have\ndifferent owner/host lifetimes; resolve that contract before wiring the runtime.\nReuse Core's public lifecycle, discovery and state owners rather than parallel\nadapter implementations. Keep identity and host configuration data-driven.\n\nApplication UI uses project-owned `dcc-cua` / `ui-control`. Before observation\nor input report `provider=dcc-cua runtime=<version> pid=<exact-pid> hwnd=<exact-native-hwnd>`.\nMissing binding blocks actions. Read the bundled `dcc-cua` skill for UI work;\nnever fall back to generic Computer Use without the user's explicit change of provider.\n\n## Choose relevant guidance\n\n| Work | Read |\n|---|---|\n| New or modernized public adapter | [Adapter workflow](references/ADAPTER_WORKFLOW.md), [host patterns](references/HOST_PATTERN_MATRIX.md) |\n| Private standalone service | [Internal service workflow](references/INTERNAL_SERVICE_WORKFLOW.md) |\n| Server ownership, host dispatch, state digest, UI integration, gateway or sidecar wiring | [Runtime integration](references/RUNTIME_INTEGRATION.md); consult its relevant numbered contracts |\n| Proposed adapter-local workaround for shared behavior | [Core escalation](references/CORE_ESCALATION_CHECKLIST.md) |\n| Async/main-thread jobs, cancellation or reconnect | [Async recovery](references/ASYNC_RECOVERY.md) |\n| Runtime failure or issue ownership | [Failure routing](references/FAILURE_ROUTING.md) |\n| Nuke/standalone examples or cross-DCC file synchronization | [Integration examples](references/INTEGRATION_EXAMPLES.md) |\n| Validation or release | [Testing and release](references/TESTING_AND_RELEASE.md) |\n\nUse the `dcc-mcp` route only when live validation is needed; source-only edits\ndo not require starting a host, installing a CLI, or updating a server.\nRun the relevant local checks, fix failures caused by the change, and verify the\nrequested behavior before reporting completion. Keep source/mock validation\nseparate from real-host acceptance. Publishing requires the requested scope\nand the applicable release gates; native Python 3.7 remains an LTS profile,\nand `py37-lite` does not satisfy its release gate.\n\n## Non-Negotiables\n\n- Do not touch a DCC API from a Tokio/HTTP worker thread.\n- Do not parse or rewrite `SKILL.md`, `tools.yaml`, `groups.yaml`, or prompt/workflow files in adapter runtime code when core exposes a typed object or catalog API.\n- Do not reach into `server._server` unless no public core API exists; if you must, file a core issue and keep the adapter shim small.\n- Do not create Maya-only abstractions in shared core or adapter templates.\n- Do not expose raw script execution as the primary user workflow when a typed skill can cover the task.\n- Do not require GitHub, a public catalog entry, or public issue tracking for a private internal service.\n- Do not publish local paths, private machine names, or source-attribution markers in public issues or PR text.\n\nFile v0.19.107:_meta.json\n\n{\n  \"ownerId\": \"kn79keq1bp4t91s48e3x1fk3jn82w8hf\",\n  \"slug\": \"dcc-mcp-creator\",\n  \"version\": \"0.19.107\",\n  \"publishedAt\": 1790695609044\n}\n\nFile v0.19.107:references/ADAPTER_WORKFLOW.md\n\n# Adapter And Service Workflow\n\nUse this reference to build a new adapter, expose an internal standalone\nservice, or simplify an existing integration.\n\n## 1. Choose the Runtime Shape\n\nUse the smallest shape that can honestly run the host API:\n\n| Host shape | Typical DCCs | Recommended path |\n|---|---|---|\n| Embedded Python, GUI | Blender, Houdini, Maya, 3ds Max Python | `DccServerBase` with `HostExecutionBridge` and a host dispatcher |\n| Embedded Python, headless | mayapy, Blender background, Houdini hython | `DccServerBase` with inline or blocking dispatcher |\n| External bridge | ZBrush, Photoshop, Unity, proprietary tools | `DccServerBase` plus IPC/WebSocket/HTTP bridge helpers |\n| Editor/game engine | Unreal, Unity | Adapter-owned plugin bridge plus typed skill tools; keep Python optional |\n| Standalone internal service | Asset/review/render APIs, private CLI tools | `DccServerBase` with `instance_type=\"standalone\"`, no DCC PID, and inline typed tools |\n\nWhen an external bridge uses the public Python `DccBridge` WebSocket server,\ndeclare `dcc-mcp-core[bridge]`; the base install intentionally does not pull in\nthe optional `websockets` transport.\n\n## 2. Build the Composition Root\n\nAdapter server modules should be composition roots, not utility bins. Keep them\nresponsible for wiring only:\n\n- Resolve options with `DccServerOptions.from_env(...)`.\n- Pass the adapter's bundled `skills/` directory.\n- Attach `HostExecutionBridge` before skill discovery.\n- Register resources, project tools, diagnostics, prompts, and adapter\n  instruction resources before `start()`.\n- Keep `start_server()` and `stop_server()` thin wrappers.\n\nMinimal skeleton:\n\n```python\nfrom pathlib import Path\n\nfrom dcc_mcp_core import DccServerBase, DccServerOptions, HostExecutionBridge\n\n\nclass MyDccServer(DccServerBase):\n    def __init__(self, port: int | None = None, dispatcher=None, **kwargs):\n        bridge = HostExecutionBridge(dispatcher=dispatcher) if dispatcher else None\n        options = DccServerOptions.from_env(\n            \"mydcc\",\n            Path(__file__).parent / \"skills\",\n            port=port,\n            execution_bridge=bridge,\n            **kwargs,\n        )\n        super().__init__(options=options)\n\n    def _version_string(self) -> str:\n        return \"unknown\"\n```\n\nKeep `port=None` as the adapter default. Core resolves an explicit argument\n(including `0`) first, then `DCC_MCP_<DCC>_PORT`, then `0` so the OS assigns a\nfree loopback port. Clients discover the bound endpoint through FileRegistry\nor the gateway; use an explicit argument or environment value only when a\nfixed direct endpoint is required.\n\nFor `HostUiDispatcherBase` subclasses, the bridge creates and attaches the\nnative HTTP main-affinity queue automatically. Keep the host timer calling the\nsubclass's `drain_queue()`; do not wire a second queue in the adapter.\n\nGuard the adapter's outer startup import with\n`capture_bootstrap_errors(dcc_name, adapter_version=..., min_core_version=...)`.\nIt records pre-server failures and re-raises them for the host's native error\nUI. `DccServerBase` captures Python logging and uncaught runtime exceptions\ninto the shared log plus `output://` / `events://`; forward host-native console\ncallbacks with `server.report_host_error(...)`. Do not install a second sink or\nreplace process-wide stdout/stderr.\n\nFor a non-DCC standalone service, keep the same composition root but omit\n`HostExecutionBridge`, pass `instance_type=\"standalone\"`, and leave `dcc_pid`\nunset. Follow [INTERNAL_SERVICE_WORKFLOW.md](INTERNAL_SERVICE_WORKFLOW.md); a\npublic repository and public catalog entry are not required.\n\n## 3. Add Progressive Skills\n\nUse `MinimalModeConfig` for startup policy:\n\n```python\nfrom dcc_mcp_core import MinimalModeConfig\n\nminimal = MinimalModeConfig(\n    skills=(\"mydcc-scripting\", \"mydcc-scene\"),\n    deactivate_groups={\"mydcc-scene\": (\"heavy\",)},\n    env_var_minimal=\"DCC_MCP_MYDCC_MINIMAL\",\n    env_var_default_tools=\"DCC_MCP_MYDCC_DEFAULT_TOOLS\",\n)\nserver.register_builtin_actions(minimal_mode=minimal)\n```\n\nOnly eager-load the skills needed for discovery, diagnostics, and a first useful\nscene query. Leave authoring, render, export, and pipeline skills loadable on\ndemand.\n\nFor ordinary standalone Python adapters installed in a virtual environment,\nleave `DCC_MCP_PYTHON_EXECUTABLE` unset. The subprocess executor resolves an\nexplicit override first, then the active PyO3-attached `sys.executable` when it\nis a real Python CLI, and finally `python` on `PATH` for pure-Rust callers. This\nkeeps adapter and Core packages visible to Skill scripts even when the virtual\nenvironment is not first on `PATH`. Core does not auto-select host GUI binaries\nsuch as Blender, Maya, FreeCAD, or OpenSCAD. Embedded hosts should keep using an\nin-process `HostExecutionBridge`, or set an explicit vendor CLI such as\n`mayapy`, `hython`, or `c4dpy` only when subprocess execution is intentional.\n\n## 4. Publish Adapter Context\n\nPrefer core-owned surfaces:\n\n- `set_context_snapshot_provider(...)` for post-tool scene/document context.\n- `register_adapter_instructions(...)` for adapter instruction resources.\n- `register_project_tools(...)` for resumable project state.\n- `server.resources()` or a public resource binder when available.\n- `plugin_manifest(...)` for machine-readable install metadata.\n\nIf a needed adapter context requires private inner-server access, keep the shim\nin one adapter-local module and open a core issue.\n\n## 5. Decide What Belongs in Core\n\nEscalate to core when more than one adapter would need the same helper:\n\n- skill metadata lifecycle hooks;\n- host-thread readiness bits;\n- resource registration patterns;\n- sidecar/install lifecycle;\n- gateway search/describe/call response shape;\n- UI Control automation contracts;\n- file/artifact handoff;\n- diagnostics, agent trace packets, compact debug negotiation, and issue-report exports.\n\nAdapter repositories should contain host facts and host API calls. Core should\nown reusable MCP, gateway, catalog, lifecycle, and wire contracts.\n\nAdmin issue reports are public-safe by default. They should expose request\nstatus, DCC type, tool family, timing, sanitized error kind, token accounting,\nredaction status, and relative debug links without raw payload previews or local\nmachine details. Full debug bundles remain a core-owned explicit raw export\n(`?mode=raw`) for reviewed local evidence only.\n\nGateway/admin token accounting has two distinct concepts. Payload token fields\n(`payload_token_usage`, `payload_token_accounting`, trace input/output tokens)\nestimate captured request/response previews and must report missing coverage\nexplicitly. Response token accounting (`token_usage`, `response_token_accounting`,\noriginal/returned/saved tokens) describes JSON/TOON compaction savings and must\nnot be used as a substitute for missing payload estimates.\n\nFile v0.19.107:references/ASYNC_RECOVERY.md\n\n## Chunked Main-Thread Jobs\n\nUse the shared chunked path when a main-affinity operation cannot finish within\none host UI tick. The adapter owns scheduling; skill code only defines bounded\nsteps:\n\n```python\nfrom dcc_mcp_core import chunked_job\n\n@chunked_job(total=100)\ndef bake_frames():\n    for frame in range(100):\n        yield lambda frame=frame: bake_one_frame(frame)\n\n# A declarative in-process tool returns this runner. HostExecutionBridge\n# detects and submits it to HostUiDispatcherBase automatically.\nreturn bake_frames()\n```\n\n- Declare `execution: async`, `affinity: main`, and\n  `job_strategy: chunked`. The bridge rejects a declared chunked tool that\n  returns a monolithic value.\n- Any operation that can exceed the caller's synchronous timeout must return a\n  job envelope. Declare `execution: async` and provide a realistic positive\n  `timeout_hint_secs`; Core routes the execution declaration through\n  `JobManager`. A timeout hint only sizes client/runtime budgets and never\n  promotes an `execution: sync` tool to an async job.\n- Yield one bounded host-API callable per step. A returned string becomes the\n  progress message.\n- `submit_chunked_runner()` advances at most one step per host pump tick, so\n  unrelated UI work can run between steps.\n- `cancel(request_id)` requests cancellation. The runner publishes\n  `cancelled` only after the next checkpoint observes it; a running native DCC\n  call or monolithic callback is not pre-empted.\n- Do not add adapter-local generator pumps, timer loops, worker threads, or a\n  second job registry.\n- Test pending cancellation, cancellation during a step, monotonic progress,\n  failure, exactly one terminal result, unrelated pump work, and at least two\n  host labels.\n\nDo not label an indivisible native call as chunked. Use\n`job_strategy: monolithic` when the host API cannot yield, or\n`job_strategy: isolated` when a process/service-owned operation can return a\ndurable job id. Isolated status must remain queryable after transport loss;\ncancellation may remain process-owner scoped when reconstructing ownership\nwould be unsafe.\n\n## Liveness and Crash Recovery\n\n- Keep registry heartbeat and HTTP readiness independent of the DCC main\n  thread. A readiness/transport timeout marks the instance `unreachable`; it\n  must not erase a row whose owner lock/PID or remote TTL is still valid.\n- Keep HTTP body limits, trusted-proxy depth, and request-rate windows on the\n  owning `GatewayState` (`GatewayIngressState`). Embedded adapters may host\n  more than one gateway in a process, so process-global lazy counters or env\n  snapshots are not a valid isolation boundary.\n- Keep backend retry policy and circuit observations on the same owning\n  `GatewayState` through `GatewayResilienceState`. Pass that state through\n  backend discovery and dispatch calls; never use a process-global circuit\n  table, because one embedded gateway must not open another gateway's backend.\n- Pass the complete `McpHttpConfig.features` snapshot into HTTP runtime state\n  with `ServerStateBuilder::with_features`. Do not copy capability booleans\n  into loose `ServerState` fields; config and runtime routing must read the\n  same `FeatureFlags` source.\n- In Rust async gateway/adapter code, share `Arc<FileRegistry>` directly and\n  call its `*_async` methods. `FileRegistry` is already internally synchronized;\n  an outer `RwLock` adds no safety and holding an async guard across its\n  flock/fsync transaction blocks the runtime.\n- Treat owner lock/PID death or remote TTL expiry as crash evidence. After a\n  crash, the adapter cannot reconnect until the DCC or sidecar starts again.\n- Preserve stable `dcc_type`, scene/project metadata, and adapter identity so\n  agents can rediscover a replacement instance. Never reuse an old tool slug\n  or direct MCP URL after the instance id changes.\n- Enable core job persistence. On restart, in-flight core jobs become\n  `interrupted` and remain queryable through the replacement instance's\n  `jobs_get_status`; adapter-owned isolated jobs need their own durable status\n  tool when they outlive the request transport. If the worker can outlive the\n  DCC/sidecar process, that status tool must be owned by the worker/service or\n  another independently live control process; gateway restart alone cannot\n  recreate an API whose owner exited.\n- A bounded SQLite shutdown may return before an in-flight statement has\n  quiesced. Core closes the old handle immediately but retains its physical\n  ownership lease until every admitted operation exits; do not start a\n  replacement owner until acquisition succeeds. Never bypass the lease or\n  reuse a second path alias to the same database.\n- Read `job_persistence` from the server `/health` payload before claiming\n  durable job history. `degraded` means recent writes failed; `disabled` means\n  the manager latched repeated failures and is serving jobs from memory only.\n  `last_error_kind` is a stable category (`readonly`, `wal`, `busy`,\n  `disk_full`, `decode`, `feature_disabled`, `retention_prune_failed`,\n  `server_shutdown`, or `backend`) for diagnostics.\n  Do not expose backend messages or filesystem paths from that status.\n  Gateway `/admin/api/health` and `/v1/debug/health` aggregate the same\n  payload-safe state per registered backend; `unavailable` means the backend\n  did not answer the bounded admin read.\n  A `retention_prune_failed` latch recovers only after a real backend prune\n  succeeds. An empty cleanup is a no-op and must leave that health state\n  disabled because it did not verify storage recovery.\n  `job_retention_hours` is opt-in startup pruning of terminal rows only;\n  leave it unset when retention ownership is not established.\n- Make every adapter-owned launch return its durable `job_id` and one canonical\n  status (`pending`, `running`, `completed`, `failed`, `cancelled`, or\n  `interrupted`). Declare its status tool in `next-tools.on-success`. Automatic\n  CLI waiting is allowed only when that poller is `execution: sync`, marks both\n  `read_only_hint` and `idempotent_hint` true, and declares a string `job_id` as\n  its only required input. Every other input must be optional and safe when\n  omitted. The poller must query exactly that ID and return authoritative progress; an\n  unknown ID is an explicit error, never permission to mint a replacement job.\n\nFile v0.19.107:references/CORE_ESCALATION_CHECKLIST.md\n\n# Core Escalation Checklist\n\nUse this before adding adapter-local framework code. If the answer is \"yes\" for\ntwo or more adapters, prefer a core issue/RFC.\n\n## Escalate to Core\n\nOpen a core issue when the adapter needs:\n\n- a lifecycle hook around skill discovery, skill load, unload, group activation,\n  resource subscription, client initialize, or tool dispatch;\n- a typed skill object transform that must apply to programmatic, MCP, REST, and\n  gateway load paths;\n- a public `DccServerBase` wrapper over a private inner server API;\n- a reusable resource/prompt/project registration pattern;\n- a readiness bit or health check shared by host dispatchers;\n- a gateway search/describe/call response field;\n- install, uninstall, or sidecar lifecycle behavior;\n- cross-DCC UI Control automation contracts;\n- common artefact/file handoff and retention behavior;\n- policy, audit, telemetry, or debug bundle fields.\n\nBefore adding a protocol DTO, check\n[`ADR-027`](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/adr/027-protocol-type-ownership.md). Adapters and\ngateway applications consume the canonical core type directly, re-export it\nfor compatibility, or use an explicit conversion when their invariants differ;\nthey do not copy generic JSON-RPC, MCP, wire, or transport fields locally.\n\n## Keep Local to the Adapter\n\nKeep code adapter-local when it is only:\n\n- the host's import path, version query, or startup hook;\n- the exact host API call, such as `bpy.ops`, `pymxs.runtime`, or Unreal editor APIs;\n- a DCC-specific menu, shelf, plugin, or bootstrap script;\n- domain tool behavior that belongs to one DCC skill package;\n- a studio-specific deployment policy.\n\n## Current Core Requests From Adapter Review\n\n- [RFC: add adapter skill-load transform hooks](https://github.com/dcc-mcp/dcc-mcp-core/issues/1204): adapters need a core-owned hook so metadata transforms apply consistently to programmatic `load_skill`, MCP `load_skill`, REST `/v1/load_skill`, and gateway-mediated loads.\n- [RFC: expose public DccServerBase resource registration surface](https://github.com/dcc-mcp/dcc-mcp-core/issues/1205): adapters need a public resource handle/helper instead of private inner-server access.\n- [RFC: add reusable adapter readiness binder](https://github.com/dcc-mcp/dcc-mcp-core/issues/1206): embedded adapters need a shared readiness binder for process, dispatcher, host-execution, main-thread, and DCC-ready state.\n\n## Issue Template\n\n```markdown\n## Problem\n\nDescribe the adapter-local code that should not be repeated in every DCC repo.\n\n## Requested Core Surface\n\n- API name or shape.\n- Which load/call/resource/readiness paths it must cover.\n- Expected error and observability behavior.\n\n## Acceptance Criteria\n\n- At least one Python adapter test.\n- At least one MCP or REST path test when the behavior crosses HTTP.\n- Backward compatibility notes for existing adapters.\n```\n\nPublic issue text must be portable. Do not include local paths, private\nhostnames, machine-specific logs, or source-attribution markers.\n\nFile v0.19.107:references/FAILURE_ROUTING.md\n\n## Failure Analysis and Bug Routing\n\nReproduce through `dcc-mcp` and keep one gateway session id. Run\n`dcc-mcp-cli doctor`, then `dcc-mcp-cli stats --status failure --session-id\n<session-id>`; preserve the failed call's `request_id`, trace/job ids, adapter\nversion, DCC version, readiness fields, and the smallest safe reproduction.\nUse `/v1/debug/issue-reports/<request_id>` for the public-safe issue body and\nreview any `?mode=raw` export locally before sharing it.\nThe bundled error report binds persisted-job diagnostics to the exact current\ninstance key. If that database is absent, report persistence as unavailable;\nnever glob a sibling instance or fall back to another process's database.\nIt likewise binds rolling-log diagnostics to the current DCC process PID; if\nthat exact log is absent, report logging as unavailable instead of selecting a\nsame-DCC sibling log.\n\nReport adapter-owned dispatch, host-thread, readiness, packaging, or install\nbugs in the adapter repository. Escalate shared CLI, gateway, protocol, or core\ncontract failures to `dcc-mcp-core`. Tool schema/script/workflow defects belong\nto the owning Skill and `dcc-mcp-skills-creator`. Record runtime feedback with\nthe gateway-owned `dcc-mcp-cli feedback` command so the report remains possible\nafter an adapter or DCC process exits; include the last known instance,\nrequest, and job ids. Instance-level `dcc_feedback__report` is the live-adapter\nFinding v1 entry point. Core must register it so runtime DCC/adapter/core/host\nversions, OS, instance id, fingerprint, and conservative redaction status are\nauto-filled; adapters must not accept agent claims for those fields or add an\nadapter-specific action/local-success fallback. Open an external issue only\nwith user authorization.\n\nCore persists accepted adapter reports under the shared registry and exposes\nthem through `dcc-mcp-cli feedback list|export` / `GET /admin/api/feedback`.\nAdapters must use `DccServerBase`'s instance-owned `FeedbackStore`; do not add a\nsecond adapter-local log, aggregation endpoint, or delete-then-copy rotation.\nThe gateway query is bounded, deduplicates by feedback id, and fails explicitly\nwhen filesystem reads or scan limits prevent a complete result.\n\nFile v0.19.107:references/HOST_PATTERN_MATRIX.md\n\n# Host Pattern Matrix\n\nUse this table when choosing adapter runtime wiring for a new DCC.\n\n| DCC family | Host API | Dispatcher approach | Notes |\n|---|---|---|---|\n| Blender | `bpy` | GUI timers or background blocking dispatcher | Keep `bpy` imports lazy so discovery works outside Blender. |\n| 3ds Max | `pymxs` / MaxPlus | Main-thread dispatcher; Python entry from startup scripts or plugin bootstrap | Treat scene mutations as main-thread-only unless proven safe. |\n| Unreal | Python, C++ plugin, or remote control | Prefer an editor plugin bridge; use Python only where deployed | Long operations should become async jobs with progress/cancellation. |\n| ZBrush | ZScript, GoZ, HTTP/IPC helper | External bridge; no embedded Python assumption | Keep bridge commands typed and bounded; avoid generic remote execution. |\n| Houdini | `hou` | Event-loop callback or headless hython dispatcher | Node graph writes are main-thread-sensitive. |\n| Maya | `maya.cmds` / OpenMaya | UI dispatcher in GUI; standalone serialized dispatcher in mayapy | Do not special-case Maya patterns into core without parameterizing host identity. |\n| Photoshop / Adobe | UXP/CEP/ExtendScript | External bridge or UI Control contract | Use structured bridge calls; do not depend on a Python-in-host runtime. |\n\nCore main-thread routing carries typed Rust results through the in-process\nexecutor. Adapters should submit through `DccDispatcher` / the core executor\nseam and must not add a JSON encode/decode envelope between same-process\nqueues. JSON remains a transport boundary only (HTTP, MCP, IPC, or host RPC).\n| Custom studio tool | Python, socket, HTTP, or CLI | Start with the least-powerful bridge that can satisfy typed tools | Document auth, scope, and shutdown behavior up front. |\n\n## Host API Rules\n\n- Import host modules inside callables or skill script entry points, never at\n  package import time.\n- Mark scene-touching tools `affinity: main`.\n- Implement REST `ToolInvoker` ports asynchronously. Core awaits host dispatch\n  directly and carries the execution context in the routed request; adapters\n  must not create a helper OS thread or a second Tokio runtime per call.\n- Use `affinity: any` only for pure file, validation, serialization, or metadata\n  operations.\n- If a tool can exceed two seconds, declare `execution: async` and a realistic\n  `timeout_hint_secs`.\n- Long host loops must check core cancellation between short chunks. Rust\n  handlers use `current_dispatch_job_context()`; metadata-driven Python skills\n  use `current_job_id()` because reserved `_meta` keys are not forwarded to\n  `main()`. Use `check_dcc_cancelled()` in Python and\n  `DispatchJobContext::is_cancelled()` in Rust. Never trust or mint a\n  client-supplied job id.\n- Interactive Python hosts should use `@chunked_job` and\n  `HostUiDispatcherBase.submit_chunked_runner()` so the shared pump executes at\n  most one bounded step per tick. Do not add an adapter-local generator pump.\n- The built-in propagation contract covers in-process Rust/Python handlers over\n  MCP and REST. Subprocess, native IPC, and remote bridge adapters must forward\n  both the server-owned job id and cancellation signal explicitly, then prove\n  that wiring in an adapter test.\n- Cancellation requests skip queued work and cooperatively stop running chunks\n  when the execution lane acknowledges the next checkpoint. They\n  cannot safely interrupt a DCC-native API call or an uncooperative hot loop\n  already executing on the host thread; use typed, bounded operations and\n  return control to the pump between chunks.\n- Every bridge path must normalize arguments and return the canonical domain\n  result envelope: `error` is a string code and structured details belong under\n  namespaced `_meta` entries. `HostExecutionBridge` and in-process dispatchers\n  must not return a JSON-RPC-style error object in the domain `error` field.\n  Keep outer host-RPC `{result}` / `{error}` transport envelopes separate.\n\n## Dispatcher Smoke Tests\n\nEach adapter should have at least one smoke that proves:\n\n- the server starts without a GUI import at discovery time;\n- a main-affinity tool runs through the host dispatcher, not the HTTP worker;\n- a pure `any` tool can run without blocking the host UI;\n- cancellation or timeout produces a structured error;\n- gateway REST or direct MCP can search, load, describe, and call one typed tool.\n\nFile v0.19.107:references/INTEGRATION_EXAMPLES.md\n\n## Example: New Nuke Adapter\n\nWhen asked to create a Nuke MCP adapter, start by mapping the host lifecycle:\nhow Python is loaded, how the UI/main thread must be entered, what headless\nmode is available, how plugins are installed, and which operations should be\nbundled as default skills. Then scaffold the adapter around core primitives:\n\n- `DccServerBase` for MCP/HTTP and skill catalog behavior.\n- `DccServerOptions.from_env(\"NUKE\")` or an adapter-specific equivalent for env-driven configuration.\n- `HostExecutionBridge` plus a Nuke dispatcher for all Nuke API calls.\n- Core project, readiness, resource, diagnostics, and gateway helpers before adapter-local glue.\n- `dcc-mcp-skills-creator` for the first `nuke-*` skill packages.\n\n## Example: Private Non-DCC Service\n\nWhen asked to expose an internal asset, render-farm, review, or production\nservice, stay in the supplied private project and start with\n[`examples/remote-server`](https://github.com/dcc-mcp/dcc-mcp-core/tree/main/examples/remote-server). It is a standalone\nservice despite the historical directory name: it binds to loopback for local\ndevelopment, discovers a bundled example Skill, and needs no DCC process or GitHub\nrepository.\n\n- Use a stable custom identifier such as `studio-assets`; do not pretend it is\n  Maya or another cataloged DCC.\n- Pass `instance_type=\"standalone\"`, leave `dcc_pid` unset, and use inline\n  execution unless a real external host boundary exists.\n- Validate the Skill, start the service, then exercise `tools/list`,\n  `tools/call`, resources, and errors with the official open-source MCP\n  Inspector before testing gateway discovery.\n- Keep development on loopback. Intranet exposure requires operator-owned\n  TLS, authentication, firewall policy, secret storage, and audit controls.\n- Package through the owner's existing wheel, archive, container, Rez, or\n  private registry workflow. Do not create or publish a public repository\n  unless the user explicitly requests it.\n\n## Cross-DCC Asset Sync\n\nWhen an adapter publishes an evolving file to another local or remote DCC, use\nCore's `AssetSyncRevision` and `FileAssetSyncStore` contract. Keep absolute\npaths process-local: public tools accept a relative source name, while both the\nsource root and consumer destination root come from operator configuration.\nValidate format and size before publishing, pass `expected_head_revision` for\noptimistic conflict detection, and materialize only beneath the consumer-owned\nroot. The adapter owns its native import, canvas, refresh, or watch behavior;\nCore owns only the path-free revision manifest, content-addressed object, and\nconflict/materialization rules. See `docs/guide/asset-sync.md` and ADR-021.\n\nFile v0.19.107:references/INTERNAL_SERVICE_WORKFLOW.md\n\n# Internal Standalone Service Workflow\n\nUse this path when the target is a private API, command-line service, asset\ndatabase, render farm, review system, or another non-DCC system. The source may\nlive in a local folder, intranet monorepo, Perforce workspace, or private Git\nserver. GitHub and the public DCC catalog are optional delivery choices, not\nprerequisites.\n\n## 1. Inspect Before Scaffolding\n\nRead the supplied project and reuse its language, package manager, service\nentry point, authentication, tests, and deployment path. Create a new project\nonly when no owning codebase exists. Do not add an adapter bridge when typed\ntools can call an existing library or bounded HTTP/CLI client directly.\n\nChoose one boundary:\n\n| Need | Build |\n|---|---|\n| Expose an existing private service | Standalone `DccServerBase` composition root plus typed Skills |\n| Add tools to an existing DCC-MCP runtime | A Skill package with `dcc-mcp-skills-creator` |\n| Control a GUI or host-thread-only API | A DCC adapter with `HostExecutionBridge` |\n\n## 2. Start With the Standalone Runtime\n\nUse a stable custom service id that describes ownership, such as\n`studio-assets`. Do not reuse a DCC name to bypass routing.\n\n```python\nfrom pathlib import Path\n\nfrom dcc_mcp_core import DccServerBase, DccServerOptions\n\nskills_dir = Path(__file__).parent / \"skills\"\noptions = DccServerOptions.from_env(\n    \"studio-assets\",\n    skills_dir,\n    server_name=\"studio-assets-mcp\",\n    instance_type=\"standalone\",\n)\nserver = DccServerBase(options)\nserver.register_builtin_actions(include_bundled=False)\nhandle = server.start()\nprint(handle.mcp_url())\n```\n\nLeave `dcc_pid` unset. `instance_type=\"standalone\"` describes the service\nlifetime; it does not mean `standalone_main_thread=True`. Keep default inline\nexecution for ordinary library, file, and network operations. Add a dispatcher\nor bridge only when a real thread/process boundary requires one.\n\nThe complete runnable example is\n[`examples/remote-server`](../../../examples/remote-server). Its historical\ndirectory name is retained for stable links, but its default is a loopback,\nstandalone internal service.\n\n## 3. Put Business Operations in Typed Skills\n\nLoad `dcc-mcp-skills-creator` and create one small Skill around a user workflow,\nnot one tool per private API endpoint. Every tool must have explicit input and\noutput schemas, safety annotations, bounded timeouts, and actionable errors.\nKeep credentials in the owner's secret store or process environment; never put\nthem in `SKILL.md`, `tools.yaml`, examples, logs, or result payloads.\n\nValidate before starting the service:\n\n```bash\ndcc-mcp-cli lint skills\n```\n\nFor hermetic tests, set `DCC_MCP_DISABLE_DEFAULT_SKILL_PATHS=1` so operator\nSkill directories cannot change discovery results.\n\nWhen the owner needs a reproducible development environment, prefer the open\nDevelopment Container specification and its open-source CLI over a bespoke\nsandbox. Reuse an existing `.devcontainer/devcontainer.json`; the runnable\nexample includes one under `examples/remote-server`. Keep credentials outside\nthe image and do not mount a host container socket unless the workflow truly\nneeds nested container control.\n\n## 4. Play and Debug Locally\n\nStart on loopback and print the resolved MCP URL. Use an already installed,\nproject-approved MCP client to connect with Streamable HTTP to the printed\n`/mcp` URL. The open-source\n[MCP Inspector](https://github.com/modelcontextprotocol/inspector) is optional:\nif it is needed, install a reviewed exact version through the owning project's\npackage manifest and lockfile, verify the package integrity, and run the local\ninstallation. Do not fetch and execute a floating npm version during debugging.\nKeep production credentials out of the client's environment.\n\nVerify this ladder in order:\n\n1. `tools/list` exposes only discovery/control tools before the Skill loads.\n2. List or search confirms the owning Skill and its exact slug.\n3. Load the Skill and inspect its schema.\n4. Call one read-only tool with a valid example.\n5. Call it once with invalid input and confirm the error is safe and actionable.\n6. Stop the service and confirm its registry row disappears.\n\nUse `dcc-mcp-cli list`, `load-skill`, `describe`, and `call --wait` as\nthe agent smoke once the local service is registered. Keep the returned slug\nand `request_id`; do not guess names or retry before diagnosis. If no approved\ndirect MCP client is available, complete the CLI smoke and record direct MCP\nvalidation as pending instead of installing an unreviewed debug dependency.\n\nFor a hosted multi-user teaching portal, Educates is the open-source upgrade\npath: it provides per-user isolated sessions, Markdown instructions, browser\nterminals, and an embedded editor. Treat its Kubernetes, ingress, identity,\nresource quota, image registry, and session-cleanup requirements as an\noperator-owned deployment project. A local Dev Container remains the default\nuntil that operational need exists.\n\n## 5. Expose and Deliver Privately\n\nLoopback is the development default. Before binding to an intranet interface,\nrequire the operator-owned security boundary: TLS termination, authentication,\norigin/network allow-lists, secret management, audit retention, and shutdown\nownership. Never expose the Inspector proxy to an untrusted network.\n\nUse the existing internal delivery path: wheel, signed archive, container, Rez\npackage, shared deployment system, or private package registry. A studio-owned\n`DCC_MCP_CATALOG_PATH` is useful only when operators need catalog-backed CLI\ninstall plans. Local execution and direct MCP testing do not require a public\ncatalog or GitHub repository.\n\n## Acceptance\n\n- The service starts from the owner's documented command on a clean environment.\n- One typed read-only tool succeeds through the agent path and, when direct MCP\n  validation is required, an approved MCP client.\n- Invalid input and unavailable dependency failures are structured and redacted.\n- The service is marked `standalone`, has no fake DCC PID, and shuts down cleanly.\n- Packaging uses the owner's private delivery channel with no accidental public publication.\n\nFile v0.19.107:references/RUNTIME_INTEGRATION.md\n\n# Runtime integration\n\nUse only the contracts relevant to the integration being changed. The numbered\nitems are constraints by topic, not a required sequence for every adapter edit.\n\n- Ownership and threading: vocabulary and items 1-6.\n- Shared state, scene digest and UI binding: item 7.\n- Gateway, sidecar lifecycle and readiness: items 8-9.\n- Search, task metadata, recording and experiments: remaining items.\n\nResolve `docs/guide/` references against the matching Core source checkout if\nthose documents are not shipped in the installed plugin; do not infer their\ncontents or load the entire Core documentation tree.\n\n## Runtime Vocabulary\n\n- DCC startup hook: adapter code running inside the host at application startup; it prepares env/instance data and launches the service path without blocking the DCC UI/main thread.\n- Per-DCC service: one registered runtime row for one concrete DCC instance; Python `DccServerBase` and Rust sidecars both participate as per-DCC services.\n- Sidecar: the Rust `dcc-mcp-sidecar` child launched through the stable `dcc-mcp-server sidecar` command; it bridges host RPC to MCP/REST and exits when the watched DCC dies.\n- Gateway daemon: the one machine-wide `dcc-mcp-server gateway` process that owns routing, dynamic capability search/describe/call, and Gateway Admin.\n- Guardian: a lightweight loop inside daemon-backed services that probes gateway `/health` and re-ensures the daemon through `gateway-launch.lock`; it is not a separate process.\n- Service heartbeat: registry freshness for the service row only. Do not describe heartbeat as the gateway restart trigger.\n- Service owner: the process that owns the registry sentinel and MCP endpoint; its `pid`/sentinel prove the service itself is alive.\n- Bound DCC host: optional external process identified by `host_pid`; both owner and host must stay alive. Standalone/headless services intentionally have no bound host.\n\n## Integration contracts\n\n1. Classify the ownership boundary before creating files:\n   - Public DCC adapter: run `dcc-mcp-cli dcc-types`; improve an existing\n     adapter instead of creating a duplicate. Add a genuinely new public\n     adapter to `dcc-mcp-catalog.yml` and the compatibility matrix. A pip\n     install entry requires the released universal wheel's exact HTTPS URL,\n     catalog version, and SHA-256; omit install metadata until it is published.\n   - Private non-DCC service: work in the supplied local or intranet project,\n     keep its stable custom service id private, and do not require a GitHub\n     repository, public catalog entry, issue, or release. Use a studio-owned\n     catalog only when operators need `dcc-mcp-cli install` plans.\n   - Skill package only: switch to `dcc-mcp-skills-creator`.\n2. Classify the runtime integration:\n   - Embedded Python host: Blender, 3ds Max Python, Houdini, Maya, Nuke.\n   - External bridge host: ZBrush, Photoshop, Unity, custom tools.\n   - Game/editor host with mixed Python or C++ bridge: Unreal, Unity.\n   - Standalone internal service: no host bridge; use inline execution for\n     ordinary service/file/API tools and keep every tool typed.\n3. Read the relevant reference:\n   - [ADAPTER_WORKFLOW.md](ADAPTER_WORKFLOW.md) for the build path.\n   - [INTERNAL_SERVICE_WORKFLOW.md](INTERNAL_SERVICE_WORKFLOW.md) for a private non-DCC service with no public repository requirement.\n   - [HOST_PATTERN_MATRIX.md](HOST_PATTERN_MATRIX.md) for host-specific wiring.\n   - [CORE_ESCALATION_CHECKLIST.md](CORE_ESCALATION_CHECKLIST.md) before adding adapter-local glue.\n    - [TESTING_AND_RELEASE.md](TESTING_AND_RELEASE.md) before validating or publishing.\n    - **Python 3.7 policy**: native py37 is an LTS profile with no automatic calendar expiry. Verify the aggregate Python 3.7 gate is green and `requires-python = \">=3.7\"` is unchanged before any release. `py37-lite` fallback does NOT satisfy release gates. Removal requires an accepted superseding ADR, a major release, and at least 180 days of notice.\n    - [docs/guide/gateway.md](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/gateway.md) for gateway daemon lifecycle details.\n    - [docs/guide/adapter-install-lifecycle.md](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/adapter-install-lifecycle.md) for sidecar launch/readiness details.\n    - [docs/guide/adapter-install-sop.md](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/adapter-install-sop.md) for the adapter-owned install, status, verify, uninstall, and upgrade contract.\n    - [docs/guide/adapter-release-checklist.md](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/adapter-release-checklist.md) for release train compliance.\n    - [docs/guide/new-adapter-onboarding.md](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/new-adapter-onboarding.md) for new adapter scaffolding.\n    - [docs/guide/adapter-compatibility-matrix.md](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/adapter-compatibility-matrix.md) for the per-DCC compatibility table.\n4. Start from `DccServerBase` + `DccServerOptions.from_env(...)`.\n   Classify the runtime lifetime explicitly:\n   - Embedded adapter: the service owner is the DCC process; no separate host PID is needed.\n   - Standard sidecar: pass `watch_pid=current_dcc_pid`; core publishes the sidecar owner and bound host as separate liveness signals.\n   - Other out-of-process adapter: pass `dcc_pid=current_dcc_pid` so `McpHttpConfig.host_pid` binds discovery to the DCC lifetime.\n   - Standalone/headless service: pass `instance_type=\"standalone\"`, leave `dcc_pid` unset, and do not bind it to an optional GUI process. Runtime identity is independent from `standalone_main_thread`, which controls tool execution only.\n5. Route host API calls through `HostExecutionBridge`; do not hand-roll a second script executor. Standalone services with no host-thread boundary should keep the default inline execution path.\n   For file-backed typed `main(**params)` execution, publish mapping annotations\n   only when their keys are strings (`Dict[str, V]`). Validate the requested\n   SHA-256, derived schema, and structured params before materializing inline\n   source; an invalid request must leave no script or sidecar file behind.\n6. Keep service identity data-driven: `dcc_name`/custom service id, `server_name`, env-var prefix, skill names, and gateway metadata.\n   Leave the instance port unset so core resolves `DCC_MCP_<DCC>_PORT` or asks the OS for a free port.\n7. Use core helpers for skill discovery, `MinimalModeConfig`, project tools, resources, diagnostics, context snapshots, install lifecycle, and gateway failover before writing adapter-local wrappers. Python `DccServerBase.collect_skill_search_paths()` includes marketplace-installed skills under `~/.dcc-mcp/marketplace/<dcc>` (or `DCC_MCP_MARKETPLACE_INSTALL_ROOT/<dcc>`) when the directory exists, so adapters should not add a second marketplace path convention. Hermetic adapter tests should set `DCC_MCP_DISABLE_DEFAULT_SKILL_PATHS=1`; this excludes implicit local/platform defaults, marketplace installs, and Admin custom paths while explicit, bundled, and environment-provided skill paths remain active.\n   `DccServerBase` also owns `DiagnosticRuntimeState`; do not add adapter-level\n   recorder, sandbox, screenshot-capturer, dispatcher, server, or instance-context\n   globals. Standalone registration code may inject one state into both\n   diagnostic registration helpers.\n   It also owns `feedback_store`, `script_execution_context`, and\n   `checkpoint_store`; inject them into core helpers instead of creating\n   adapter-level feedback buffers, persistent exec namespaces, or default stores.\n   Adapters that expose `execute_python` should capability-gate cheap scene-state\n   evidence by registering one host-owned callback with\n   `register_state_digest_provider(..., context=server.script_execution_context)`.\n   The callback returns `SceneStats` or its mapping shape (`object_count`,\n   `vertex_count`, `has_mesh`, optional `extra`). Run scripts through\n   `execute_with_state_digest(...)`; its native transaction pins that exact\n   provider for both observations and returns public `SceneDigestSnapshot`\n   values. A script cannot replace the provider used by its active transaction\n   or poison the next transaction through `ScriptExecutionContext`. Pass both\n   snapshots to `ScriptExecutionResult.from_value(...)`. Core bounds and redacts\n   the payload, computes a deterministic fingerprint, and fails closed when the\n   provider is absent, raises, returns malformed data, or supplies a mismatched\n   fingerprint.\n   Digest change proves only that observed state changed; leave `verified`\n   omitted/false unless an adapter-owned postcondition verifies the claimed\n   effect. Never turn contract-test evidence into a real-host success claim.\n   The fingerprint and truncation marker detect deterministic corruption; they\n   are not authentication, authorization, or proof of host identity. Core does\n   not expose a Python secret, signing oracle, signed wire tag, or native factory\n   that turns caller-supplied bytes into authenticated evidence. The adapter\n   registers the provider before the native transaction starts, but that does\n   not establish cryptographic authenticity; semantic verification remains\n   adapter-owned. Pure-Python runtimes without that boundary fail closed with\n   `scene_digest_custody_unavailable`. Mapping\n   values beyond the bounded observation budget use a fixed sentinel, keeping\n   equivalent provider mappings deterministic without unbounded reads.\n   Core does not auto-register or advertise an `execute_python` route. Gate\n   adapter discovery and route registration on successful provider\n   registration, and expose `unavailable/provider_missing` when\n   `capture_state_digest(...)` reports no provider.\n   If the script raises `Exception` or `BaseException`, the transaction performs\n   after-state readback first. Catch `SceneDigestExecutionError` and pass its\n   `cause`, snapshots, and `readback_error` to\n   `ScriptExecutionResult.from_exception(...)`.\n   A failed after-readback after a mutating script is explicitly\n   `indeterminate=true` with `verified=false`; preserve the before snapshot and\n   never retry it as if no side effect occurred.\n   Core persists gateway-accepted feedback under\n   `<registry_dir>/feedback/<dcc>-<pid>.jsonl` with bounded rotation and\n   session-end syncing. Treat `feedback_persistence_failed` as a real degraded\n   result; never add an adapter-local success fallback.\n   - For native visual UI fallback, reuse the bundled `ui-control` skill with\n     standalone `dcc-cua` 0.4.0 or newer; do not add adapter-local capture,\n     accessibility, or raw-input wrappers. Keep stateful UI calls in one\n     long-lived adapter process so each logical session retains its persistent\n     CUA bridge and window capability. Preserve `capture_provenance` with\n     evidence. The shared CUA Host owns platform accessibility, capture,\n     banner/border/cursor markers, Escape interruption, input serialization,\n     and recording. `ui-control` remains `requires_in_process: true` with\n     `affinity: any`; register `HostExecutionBridge` before skill loading.\n   - Keep structured DCC skills, host APIs, and adapter scripts ahead of\n     `ui-control`. Agents should make an explicit, agent-directed transition into the scoped\n     `snapshot` → one `act` → `snapshot` loop only when an operation is\n     unsupported, no suitable tool exists, or semantic UI Automation cannot\n     reach the required control. Re-observe after every action.\n   - For native application menu bars, route an explicit `menu_path` through\n     `ui_control__act(action=\"invoke_menu\")` when semantic click or Alt-mnemonic\n     delivery cannot prove that a Qt popup opened. Require the negotiated\n     `native_menu_path` Host capability, honor `verification_required`, and\n     re-observe the exact window before another mutation.\n   - Raw pointer and keyboard input are enabled by default only inside the\n     adapter/operator-bound DCC scope. Operators may set\n     `DCC_MCP_CUA_ALLOW_RAW_INPUT=false` to disable that runtime ceiling; the\n     adapter must not override this choice. Populate `DccServerOptions` with\n     the adapter's DCC PID and, when available, its current window title or\n     handle; Core injects that trusted scope into in-process `ui-control` calls.\n     Dedicated servers may instead use `DCC_MCP_UI_CONTROL_PROCESS_ID` or\n     `DCC_MCP_UI_CONTROL_WINDOW_HANDLE` operator overrides. Request scope may\n     only narrow that trusted PID/HWND, including a title constraint for one\n     window inside a multi-window process. Require a visible unlocked desktop\n     and matching Windows integrity level, preserve the click-through\n     border/banner/pointer feedback, and preserve\n      `user_interrupted` without automatic retry, `session_id` changes, or fallback. Once Esc stops an\n      session, only `ui_control__snapshot(resume_computer_use=true)` may request a\n      resume, and the isolated host must still obtain trusted user confirmation\n      before clearing the latch. Always call `ui_control__stop_computer_use` when\n      the workflow ends.\n      Never transition or retry through another UI/input path after a policy,\n      authorization, authentication, security, confirmation,\n      `desktop_unavailable`, or `user_interrupted` result.\n      Keep mutating UI Control tools annotated as destructive. The optional\n      `intent` may only raise the native host's independent UIA/input\n      classification. Do not introduce a model-supplied `confirmed`/`approved`\n      flag or environment bypass.\n8. Use CLI profiles (`dcc-mcp-cli gateway ...`, `list/search/describe/call`) as the user UX; treat `dcc-mcp-server` modes as runtime plumbing. Read `docs/guide/gateway.md` before changing daemon, guardian, sentinel, registry, or idle-timeout behavior.\n   Gateway discovery reuses a recent capability snapshot across adjacent\n   queries. Route adapter catalog changes through the existing\n   load/reload/unload contracts that force a refresh; never depend on every\n   search polling the full backend catalog.\n   `gateway://instances` is agent-safe by default and returns only live,\n   routable rows. Use `?include_stale=true`, `?include_dead=true`, or\n   `?view=all` only for explicit diagnosis; never route a call from those\n   expanded operator views without re-validating live readiness.\n   Once an instance is selected, reuse `gateway://instances/{instance_id}` or\n   `GET /v1/instances/{instance_id}/context` for live process/machine\n   performance, scene/documents, loaded skills, and canonical follow-up routes.\n   These reads fetch the backend context on demand, but scene freshness remains\n   adapter-owned: publish changes from a host event/main-thread callback with\n   `DccServerBase.update_gateway_metadata(...)`, and publish rich snapshots with\n   `set_scene_resource(...)`. Never claim scene awareness when the adapter has\n   not installed a publisher; `scene=null` / `no_scene_published` is explicit.\n   For agent observability, read `gateway://experiments/{experiment_id}` for\n   runs, Session DAG links, metrics, and Judge evidence; read\n   `gateway://governance` for the effective policy boundary. Keep Admin memory\n   deletion controls out of agent-readable resources.\n9. Use `dcc_mcp_core.deployment.build_sidecar_command(...)` / `launch_sidecar(...)` for library-driven sidecar startup and readiness. Installer subprocesses should use `dcc-mcp-install-lifecycle`; `dcc_mcp_core.install_lifecycle` and `python -m dcc_mcp_core.install_lifecycle` remain compatibility aliases. Read `docs/guide/adapter-install-lifecycle.md` before changing host RPC, dispatch readiness, launch stdio, `watch_pid`, or `instance_id` handling.\n   - Adapter-owned lifecycle commands must follow `docs/guide/adapter-install-sop.md`. Consume `load_install_sop_schema()` and `INSTALL_EXIT_CODES` from `dcc_mcp_core.deployment`; do not invent adapter-local result shapes or exit-code mappings.\n   - The sidecar MCP listener is dispatch-only. A py37-lite factory can expose local skill metadata, but it cannot advertise or activate declarative skills through the gateway. Require a native py37 wheel for that path, or provide a separate discovery MCP URL; never report lite `load_skill` success without an executable catalog.\n   - Wrap the outer adapter import/start block with `capture_bootstrap_errors(...)`; it is stdlib-only, records pre-MCP failures, and re-raises for the DCC's native error UI. `DccServerBase` already captures Python error logs and uncaught exceptions into the shared log plus `output://` / `events://`. Forward host-native console callbacks with `server.report_host_error(...)`; do not replace global stdout/stderr or add an adapter-local error store.\n   - For DCC-Link IPC upgrades, deploy readers that accept current version 1 and legacy version 0 before switching writers to the default versioned frame. Use `DccLinkFrame(..., version=0)` only during that compatibility window, preserve an incoming frame's version in its reply, and treat `unsupported DCC-Link protocol version` as an explicit peer-upgrade failure rather than retrying body decoding.\n   - Preserve one caller-generated request id across every execution hop. JSON-RPC responses must echo `id`; commandPort-style sidecar responses must echo top-level `request_id`; gateway REST responses must echo `X-Request-ID`. Never replace an explicit response id with the current request id, because that can disguise a stale response. Treat a missing or mismatched echo as `transport desync`, fail closed, and regression-test a slow call followed by fast calls on the same connection.\n   - Registry producers must write `ServiceEntry.schema_version` using `SERVICE_ENTRY_SCHEMA_VERSION`; rows with no field are legacy version 0. Consumers may read legacy/current rows but must reject a higher schema version without quarantining, deleting, or rewriting `services.json`. Treat that error as an explicit peer-upgrade requirement, not as corrupt JSON.\n10. Pass `instance_id` to sidecar launch helpers only when it is a real UUID for the DCC service. During early startup, omit it or pass `None`; `build_sidecar_command()` rejects cosmetic values such as `\"unknown\"` with `success=false` and `reason=\"invalid_instance_id\"` so adapters do not spawn a child that can only fail with a CLI argument error.\n    After `DccServerBase.start()`, use `server.instance_id` when adapter UI or\n    sidecar wiring needs the canonical FileRegistry identity. It is the exact\n    registered UUID and is `None` before start, after stop, or when gateway\n    registration is disabled/unavailable; never inspect private handles or\n    generate a replacement UUID.\n11. Adapter supervisors that must stop the sidecar on plugin unload should call `launch_sidecar(..., return_process=True, detached=False)` instead of reimplementing `subprocess.Popen`; keep `return_process=False` for CLI/JSON paths because the process handle is not serializable.\n12. If the adapter cannot share the gateway `FileRegistry`, register remotely through `POST /v1/instances/register`, refresh with `/heartbeat`, and deregister on shutdown; the gateway will expose the row as `source: \"http\"` in `gateway://instances` / `GET /v1/instances`, preserve `instance_short` and `mcp_url`, and route it through the same `live_instances` contract.\n    Remote registrations are untrusted input: health and capability refresh\n    only use policy-allowed, identity-matching HTTP(S) endpoints with no\n    query credentials or URL userinfo; redirects are not followed, and\n    private/link-local targets (including IPv4-mapped IPv6 literals) and DNS\n    names are rejected for periodic outbound probes. Gateway health and\n    reliability totals count only registrations accepted by that same dispatch\n    predicate; rejected registrations are reported separately and cannot\n    shadow a safe backend during DCC-type routing. Public literal IPv6\n    registrations keep an unbracketed canonical host identity; brackets belong\n    only to serialized URLs. Adapters must not copy a bracketed URL host into\n    `ServiceEntry.host` or compare raw URL text across discovery and dispatch.\n13. Keep the gateway's secondary listener on its default loopback host. Opt into LAN access only with an explicit `--remote-host 0.0.0.0` or concrete LAN IP; for same-LAN convenience discovery, build with `mdns` and pair adapter-side `--advertise-mdns` with gateway-side `--discover-mdns`. Treat mDNS as a multicast discovery hint only, keep auth/TLS policy explicit, and prefer HTTP registration or relay for routed/subnet-crossing production deployments.\n14. For NAT or routed-subnet deployments, run the tunnel agent with stable `instance_id`, `capabilities_fingerprint`, `adapter_version`, and `scene` metadata, then configure the standalone gateway with `--relay-source ADMIN_URL=PUBLIC_BASE_URL`; the gateway will expose active tunnels as `source: \"relay\"` rows with relay details in `source_meta` after probing `/v1/healthz` through `<PUBLIC_BASE_URL>/tunnel/<tunnel_id>/mcp`.\n15. Preserve gateway caller attribution when adding adapter wrappers or admin/debug routes: let legacy MCP `initialize.params.clientInfo`, MCP `_meta.agent_context`, REST `meta.agent_context`, `x-dcc-mcp-*` headers, and safe `User-Agent` fallbacks flow through core rather than logging raw prompts or local machine data.\n    The opt-in MCP 2026 path uses `server/discover` and namespaced per-request\n    metadata instead of a legacy initialize session. Consume Core's shared\n    protocol types and routing; do not copy wire envelopes into adapters or\n    Skills. Keep CLI+REST as the agent default. Before enabling a new protocol,\n    follow the [protocol compatibility gates](TESTING_AND_RELEASE.md#protocol-compatibility-gates)\n    against the exact installed artifact; a version label alone is insufficient.\n16. For lifecycle/memory/telemetry policy, use `register_lifecycle_hooks(...)`, `search_skills(..., session_id=...)`, `dispatch_session_start(...)`, `dispatch_before_tool_call(...)`, `dispatch_after_tool_call(...)`, and `dispatch_session_end(...)`; pair `MemoryRecorder(InMemoryMemoryStore()).install(hooks)` with those hooks when adapters need bounded memory summaries, failed-pattern avoidance, or session compaction. Memory injection is conservative and budgeted by default: search receives compact ranking hints, tool calls receive memory only when it matches the current `tool_name`, and session-start injection is opt-in. Use `SqliteMemoryStore()` only when longterm patterns should be durable, operator-managed in the Admin Memory tab, and included in memory hit-rate observability; disable the recorder for privacy-sensitive deployments. Open a focused core issue/RFC only when those public hooks cannot express the adapter boundary.\n17. Add one executable smoke path: unit tests for construction plus either headless DCC, mock dispatcher MCP calls, gateway REST replay, mDNS same-LAN discovery smoke, relay-source smoke, an approved local MCP client for a loopback internal service, or `just idle-memory-smoke` for standalone server idle/regression checks.\n18. For gateway/admin observability, surface explicit state instead of silent zeroes: traffic panels should report disabled, unavailable, filtered, or genuine no-traffic states; skill panels should distinguish discovered, loaded, searched, selected, called, failed, and low-adoption skills; and admin-facing frames/paths should stay metadata-only or aliased unless an operator explicitly configures a private raw sink. Keep `ServiceEntry.version` as the DCC application version; use core-published `dcc_mcp_server_version` and `dcc_mcp_instance_type=gui|standalone` metadata for server regression and runtime-shape diagnostics instead of overloading DCC or adapter versions.\n19. Preserve workflow observability: adapter calls should carry request, parent, trace, session, DCC, transport, and artifact/validation metadata so the Admin workflow graph can show Intent → Discovery → Skill Load → Tool Calls → Fallbacks → Artifacts → Validation → Report without raw log reading.\n20. Preserve bounded `agent_context` task/session/turn metadata and artifact/validation-friendly tool names so Admin task outcomes can group workflows, calls, deliverables, and checks without reading raw payloads or local paths.\n21. Preserve record-replay ownership boundaries: forward server-derived\n    `agent_context.session_id`, keep UI Control logical ids connection/caller\n    scoped, and write only redacted recording projections to existing\n    `session_events`. Do not add adapter-local recorder state, a second\n    database, or a replay authority flag. Persist calls incrementally; after a\n    gateway restart, project unfinished recordings as `interrupted` without\n    restoring capture authority. Generated workflows re-resolve current tools\n    and schemas; semantic UI replay resolves fresh control ids; raw/visual\n    fallback requires exact-window calibration and drift guards.\n22. Record reproducible experiment definitions, run states, Session DAG links,\n    metrics, and judge evidence through the gateway `/v1/experiments` APIs.\n    Reuse `session_events`, workflow/recording identifiers, and artifact\n    references; do not add adapter-local experiment storage or treat judge\n    output as approval authority.\n\nFile v0.19.107:references/TESTING_AND_RELEASE.md\n\n# Testing And Release\n\nUse the smallest test that proves the adapter contract, then add one live or\nHTTP-level smoke when behavior crosses process boundaries.\n\n## Test Layers\n\n| Layer | What to prove |\n|---|---|\n| Unit | option resolution, server construction, env vars, skill path collection |\n| Dispatcher | main-affinity calls run on the host dispatcher and return envelopes |\n| Skill lifecycle | `search_skills` -> `load_skill` -> typed tool -> `unload_skill` |\n| REST/MCP | direct `/mcp` or `/v1/*` search, then the returned `next_step` |\n| Gateway | multi-instance routing, policy, compact responses, debug traces |\n| Live DCC | one host smoke that creates/queries/cleans up real scene state |\n| Packaging | wheel or plugin archive installs into the target host runtime |\n| Install SOP | `plan -> execute -> verify -> status -> uninstall`, including rollback |\n\n## Protocol Compatibility Gates\n\nProtocol selection and wire types belong to Core. Follow the\n[Core protocol router](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/adr/033-mcp-http-protocol-router.md)\nfor the exact revision under test; adapters should not duplicate its envelopes\nor enable an opt-in protocol solely because a newer model or SDK exists.\n\n| Boundary | Required evidence when changing protocol support |\n|---|---|\n| Feature flags | Test feature-on and feature-off builds; keep legacy initialize/list/call working. Advertise only implemented handlers, providers, and notification channels. |\n| Official client | Pin the SDK and lockfile. Exercise auto negotiation and explicit version selection with discovery, a nonempty tool list, and a deterministic call. Record SDK/source differences instead of silently skipping cases. |\n| Wire contracts | Cover malformed metadata/headers, request identity, argument shape, and body limits before execution; distinguish ingress errors from in-band tool failures. |\n| Artifact | Verify the PR head, CI artifact hash, and installed native module origin. Then repeat on the published wheel/sidecar with the actual feature set; source tests are not release evidence. |\n| Execution | The same declared sync/async tool must preserve result/job semantics through REST and MCP. A timeout hint is not a substitute for `execution: async`. |\n\nSuccessful protocol tests do not prove full conformance or host correctness.\nFor response-correlation issues, also test a slow call followed by uniquely\nmarked fast calls on the same real host/session, tracing IDs through every hop.\nEchoing the current request ID around a stale payload is not a fix. After a\ntimeout, query the existing job; never replay a mutation just to flush a queue.\nKeep real-host, PR-artifact, and published-release acceptance separate.\n\n## Install SOP Gate\n\nAdapter lifecycle commands must follow\n[`adapter-install-sop.md`](../../../docs/guide/adapter-install-sop.md). Import\n`load_install_sop_schema()` and `INSTALL_EXIT_CODES` from\n`dcc_mcp_core.deployment` so machine-readable results and process exit codes\nstay compatible across adapters.\n\nThe shared Core front door preserves `install --json` as a plan and emits a\npost-execution Install SOP v1 result for `install --execute --json`. Treat the\nexecution result as evidence: assert stable per-step states, rollback outcomes,\nexit/stage/error codes, executable `next_steps`, nullable receipt state, and\nverification state. Do not infer success from the earlier plan or expose raw\npaths, subprocess output, exceptions, or secrets in either output stream.\n\nUntil live-host verification is implemented for the shared executor, a local\nartifact verification step may be `ok` while `verify.directly_usable` remains\nfalse with `LIVE_DCC_VERIFICATION_REQUIRED`. Keep that boundary in adapter\ntests instead of treating package installation as live DCC readiness.\nAny planner step that still requires operator or live-host work, such as\n`register-dcc`, must be `deferred` rather than `ok`; a zero exit code does not\nturn that manual boundary into completed registration.\n\nExercise the complete `plan -> execute -> verify -> status -> uninstall`\nround trip in CI. The gate must also prove that failed replacement restores the\nprevious usable install, stale receipt paths are diagnosed precisely, and\nbootstrap failures remain visible. A mock may prove the contract when the real\nDCC cannot run in CI; retain the documented live-host validation gap.\n\n## Validation Commands\n\nPrefer repository-native commands. For Python projects, prefer `vx uv` when it\nis available in the environment, then fall back to direct Python only when the\nwrapper is unavailable or hides behavior you need to inspect.\n\nTypical gates:\n\n```bash\npython -m ruff check src tests\npython -m ruff format --check src tests\npython -m pytest\n```\n\nFor Rust/PyO3 core changes, run the workspace's `just` or `cargo` gates that\nmatch the touched crates.\n\nFor gateway discovery performance, use deterministic tests or Criterion as the\nregression gate. If a regression needs local diagnosis, build\n`dcc-mcp-server` with `--no-default-features --features gateway-daemon,tracy`\nand follow the [local Tracy workflow](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/observability.md#6-local-tracy-profiling).\nDo not wrap async work across `.await` in a Tracy zone; correlate those phases\nwith the existing request IDs and OTLP spans instead.\n\nFor `dcc-mcp-core` toolchain or dependency refreshes, prefer vx-managed Cargo so\nlocal runs match CI:\n\n```bash\nvx cargo update\nvx cargo tree -d\nvx cargo build --workspace --all-targets --timings\n```\n\n## Live-DCC Smoke Shape\n\nEvery adapter should eventually provide one documented smoke:\n\n1. Start the DCC host in the supported mode.\n2. Start or load the adapter.\n3. Discover one skill.\n4. Load it.\n5. Call one safe typed tool.\n6. Verify host-visible state.\n7. Stop the adapter and ensure registry rows are gone.\n\nIf CI cannot run the real DCC, keep the mock HTTP test in CI and document the\nmanual live smoke command in the adapter repository.\n\n## PR Notes\n\nPR descriptions should include:\n\n- short summary of runtime or skill behavior changed;\n- validation commands, without machine-specific paths;\n- any live-DCC gap that remains;\n- exact-head terminal CI and any protocol feature, SDK, or artifact evidence;\n- the matching public Skill PR when Core changes authoring or testing contracts,\n  or a concise reason no Skill update is needed;\n- linked core issues for deferred shared APIs.\n\nFile v0.19.107:skill-card.md\n\n## Description:\n\nHelps developers build or modernize DCC-MCP adapters and standalone studio MCP services.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[loonghao](https://clawhub.ai/user/loonghao)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and studio engineers use this skill to design, implement, and validate DCC host adapters or private standalone MCP services using shared runtime contracts.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Generated adapter or service code could expose unsafe behavior when deployed beyond local development.\n\nMitigation: Review generated code before network exposure or access to production credentials; require operator-managed authentication, TLS, and network controls for intranet deployments.\n\nRisk: Project file edits or local validation commands could change or disrupt the target project.\n\nMitigation: Review proposed edits and commands, then validate changes in the owner's project before deployment.\n\n## Reference(s):\n\n- [DCC-MCP Creator skill documentation](https://github.com/dcc-mcp/dcc-mcp-agent-plugins/blob/main/plugins/dcc-mcp/skills/dcc-mcp-creator/SKILL.md)\n- [Adapter and service workflow](artifact/references/ADAPTER_WORKFLOW.md)\n- [Internal service workflow](artifact/references/INTERNAL_SERVICE_WORKFLOW.md)\n- [Testing and release guidance](artifact/references/TESTING_AND_RELEASE.md)\n\n## Skill Output:\n\n**Output Type(s):** [Code, Configuration instructions, Shell commands, Guidance]\n\n**Output Format:** [Markdown with code and command examples; project file edits when requested]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Host-specific implementation and validation guidance]\n\n## Skill Version(s):\n\n0.19.107 (source: ClawHub release metadata and skill frontmatter)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v0.19.106: 13 files, 34705 bytes\n\nFiles: agents/openai.yaml (220b), references/ADAPTER_WORKFLOW.md (6852b), references/ASYNC_RECOVERY.md (6321b), references/CORE_ESCALATION_CHECKLIST.md (3026b), references/FAILURE_ROUTING.md (2218b), references/HOST_PATTERN_MATRIX.md (4375b), references/INTEGRATION_EXAMPLES.md (2700b), references/INTERNAL_SERVICE_WORKFLOW.md (5635b), references/RUNTIME_INTEGRATION.md (25434b), references/TESTING_AND_RELEASE.md (6429b), skill-card.md (2652b), SKILL.md (4430b), _meta.json (137b)\n\nFile v0.19.106:SKILL.md\n\n---\nname: dcc-mcp-creator\ndescription: >-\n  Build or modernize DCC-MCP adapters and standalone studio MCP services. For individual tool skill packages, use dcc-mcp-skills-creator.\nlicense: MIT-0\nallowed-tools: Bash Read Write Edit\nmetadata:\n  dcc-mcp:\n    dcc: python\n    layer: infrastructure\n    compatibility: \"dcc-mcp-core 0.17+, Python 3.7+\"\n    version: \"0.19.106\"\n    search-hint: >-\n      create DCC MCP adapter, Nuke MCP, DccServerBase, HostExecutionBridge,\n      dispatcher, readiness, resources, gateway, Blender, 3ds Max, Unreal,\n      ZBrush, Houdini, Maya, standalone internal MCP service, private intranet,\n      non-DCC server, chunked main-thread jobs, cooperative cancellation\n    tags: \"adapter-development, internal-mcp-service, standalone, host-runtime, dispatcher, gateway, nuke, blender, 3dsmax, unreal, zbrush\"\n    skill-reference-docs:\n      - \"references/*.md\"\n  openclaw:\n    homepage: https://github.com/dcc-mcp/dcc-mcp-agent-plugins/blob/main/plugins/dcc-mcp/skills/dcc-mcp-creator/SKILL.md\n---\n\n# DCC-MCP Creator\n\nImplement the requested adapter or service within its owner's project. A private\nservice needs no public repository, catalog entry, issue or release. For operating\nan existing app use `dcc-mcp`; for individual tool packages use `dcc-mcp-skills-creator`.\nAn already-loaded skill needs no installation or new agent turn.\n\n## Implementation boundaries\n\nUse `DccServerBase` and `DccServerOptions.from_env(...)`, with host API calls\nthrough `HostExecutionBridge`. Embedded, sidecar and standalone services have\ndifferent owner/host lifetimes; resolve that contract before wiring the runtime.\nReuse Core's public lifecycle, discovery and state owners rather than parallel\nadapter implementations. Keep identity and host configuration data-driven.\n\nApplication UI uses project-owned `dcc-cua` / `ui-control`. Before observation\nor input report `provider=dcc-cua runtime=<version> pid=<exact-pid> hwnd=<exact-native-hwnd>`.\nMissing binding blocks actions. Read the bundled `dcc-cua` skill for UI work;\nnever fall back to generic Computer Use without the user's explicit change of provider.\n\n## Choose relevant guidance\n\n| Work | Read |\n|---|---|\n| New or modernized public adapter | [Adapter workflow](references/ADAPTER_WORKFLOW.md), [host patterns](references/HOST_PATTERN_MATRIX.md) |\n| Private standalone service | [Internal service workflow](references/INTERNAL_SERVICE_WORKFLOW.md) |\n| Server ownership, host dispatch, state digest, UI integration, gateway or sidecar wiring | [Runtime integration](references/RUNTIME_INTEGRATION.md); consult its relevant numbered contracts |\n| Proposed adapter-local workaround for shared behavior | [Core escalation](references/CORE_ESCALATION_CHECKLIST.md) |\n| Async/main-thread jobs, cancellation or reconnect | [Async recovery](references/ASYNC_RECOVERY.md) |\n| Runtime failure or issue ownership | [Failure routing](references/FAILURE_ROUTING.md) |\n| Nuke/standalone examples or cross-DCC file synchronization | [Integration examples](references/INTEGRATION_EXAMPLES.md) |\n| Validation or release | [Testing and release](references/TESTING_AND_RELEASE.md) |\n\nUse the `dcc-mcp` route only when live validation is needed; source-only edits\ndo not require starting a host, installing a CLI, or updating a server.\nRun the relevant local checks, fix failures caused by the change, and verify the\nrequested behavior before reporting completion. Keep source/mock validation\nseparate from real-host acceptance. Publishing requires the requested scope\nand the applicable release gates; native Python 3.7 remains an LTS profile,\nand `py37-lite` does not satisfy its release gate.\n\n## Non-Negotiables\n\n- Do not touch a DCC API from a Tokio/HTTP worker thread.\n- Do not parse or rewrite `SKILL.md`, `tools.yaml`, `groups.yaml`, or prompt/workflow files in adapter runtime code when core exposes a typed object or catalog API.\n- Do not reach into `server._server` unless no public core API exists; if you must, file a core issue and keep the adapter shim small.\n- Do not create Maya-only abstractions in shared core or adapter templates.\n- Do not expose raw script execution as the primary user workflow when a typed skill can cover the task.\n- Do not require GitHub, a public catalog entry, or public issue tracking for a private internal service.\n- Do not publish local paths, private machine names, or source-attribution markers in public issues or PR text.\n\nFile v0.19.106:_meta.json\n\n{\n  \"ownerId\": \"kn79keq1bp4t91s48e3x1fk3jn82w8hf\",\n  \"slug\": \"dcc-mcp-creator\",\n  \"version\": \"0.19.106\",\n  \"publishedAt\": 1789371500222\n}\n\nFile v0.19.106:references/ADAPTER_WORKFLOW.md\n\n# Adapter And Service Workflow\n\nUse this reference to build a new adapter, expose an internal standalone\nservice, or simplify an existing integration.\n\n## 1. Choose the Runtime Shape\n\nUse the smallest shape that can honestly run the host API:\n\n| Host shape | Typical DCCs | Recommended path |\n|---|---|---|\n| Embedded Python, GUI | Blender, Houdini, Maya, 3ds Max Python | `DccServerBase` with `HostExecutionBridge` and a host dispatcher |\n| Embedded Python, headless | mayapy, Blender background, Houdini hython | `DccServerBase` with inline or blocking dispatcher |\n| External bridge | ZBrush, Photoshop, Unity, proprietary tools | `DccServerBase` plus IPC/WebSocket/HTTP bridge helpers |\n| Editor/game engine | Unreal, Unity | Adapter-owned plugin bridge plus typed skill tools; keep Python optional |\n| Standalone internal service | Asset/review/render APIs, private CLI tools | `DccServerBase` with `instance_type=\"standalone\"`, no DCC PID, and inline typed tools |\n\nWhen an external bridge uses the public Python `DccBridge` WebSocket server,\ndeclare `dcc-mcp-core[bridge]`; the base install intentionally does not pull in\nthe optional `websockets` transport.\n\n## 2. Build the Composition Root\n\nAdapter server modules should be composition roots, not utility bins. Keep them\nresponsible for wiring only:\n\n- Resolve options with `DccServerOptions.from_env(...)`.\n- Pass the adapter's bundled `skills/` directory.\n- Attach `HostExecutionBridge` before skill discovery.\n- Register resources, project tools, diagnostics, prompts, and adapter\n  instruction resources before `start()`.\n- Keep `start_server()` and `stop_server()` thin wrappers.\n\nMinimal skeleton:\n\n```python\nfrom pathlib import Path\n\nfrom dcc_mcp_core import DccServerBase, DccServerOptions, HostExecutionBridge\n\n\nclass MyDccServer(DccServerBase):\n    def __init__(self, port: int | None = None, dispatcher=None, **kwargs):\n        bridge = HostExecutionBridge(dispatcher=dispatcher) if dispatcher else None\n        options = DccServerOptions.from_env(\n            \"mydcc\",\n            Path(__file__).parent / \"skills\",\n            port=port,\n            execution_bridge=bridge,\n            **kwargs,\n        )\n        super().__init__(options=options)\n\n    def _version_string(self) -> str:\n        return \"unknown\"\n```\n\nKeep `port=None` as the adapter default. Core resolves an explicit argument\n(including `0`) first, then `DCC_MCP_<DCC>_PORT`, then `0` so the OS assigns a\nfree loopback port. Clients discover the bound endpoint through FileRegistry\nor the gateway; use an explicit argument or environment value only when a\nfixed direct endpoint is required.\n\nFor `HostUiDispatcherBase` subclasses, the bridge creates and attaches the\nnative HTTP main-affinity queue automatically. Keep the host timer calling the\nsubclass's `drain_queue()`; do not wire a second queue in the adapter.\n\nGuard the adapter's outer startup import with\n`capture_bootstrap_errors(dcc_name, adapter_version=..., min_core_version=...)`.\nIt records pre-server failures and re-raises them for the host's native error\nUI. `DccServerBase` captures Python logging and uncaught runtime exceptions\ninto the shared log plus `output://` / `events://`; forward host-native console\ncallbacks with `server.report_host_error(...)`. Do not install a second sink or\nreplace process-wide stdout/stderr.\n\nFor a non-DCC standalone service, keep the same composition root but omit\n`HostExecutionBridge`, pass `instance_type=\"standalone\"`, and leave `dcc_pid`\nunset. Follow [INTERNAL_SERVICE_WORKFLOW.md](INTERNAL_SERVICE_WORKFLOW.md); a\npublic repository and public catalog entry are not required.\n\n## 3. Add Progressive Skills\n\nUse `MinimalModeConfig` for startup policy:\n\n```python\nfrom dcc_mcp_core import MinimalModeConfig\n\nminimal = MinimalModeConfig(\n    skills=(\"mydcc-scripting\", \"mydcc-scene\"),\n    deactivate_groups={\"mydcc-scene\": (\"heavy\",)},\n    env_var_minimal=\"DCC_MCP_MYDCC_MINIMAL\",\n    env_var_default_tools=\"DCC_MCP_MYDCC_DEFAULT_TOOLS\",\n)\nserver.register_builtin_actions(minimal_mode=minimal)\n```\n\nOnly eager-load the skills needed for discovery, diagnostics, and a first useful\nscene query. Leave authoring, render, export, and pipeline skills loadable on\ndemand.\n\nFor ordinary standalone Python adapters installed in a virtual environment,\nleave `DCC_MCP_PYTHON_EXECUTABLE` unset. The subprocess executor resolves an\nexplicit override first, then the active PyO3-attached `sys.executable` when it\nis a real Python CLI, and finally `python` on `PATH` for pure-Rust callers. This\nkeeps adapter and Core packages visible to Skill scripts even when the virtual\nenvironment is not first on `PATH`. Core does not auto-select host GUI binaries\nsuch as Blender, Maya, FreeCAD, or OpenSCAD. Embedded hosts should keep using an\nin-process `HostExecutionBridge`, or set an explicit vendor CLI such as\n`mayapy`, `hython`, or `c4dpy` only when subprocess execution is intentional.\n\n## 4. Publish Adapter Context\n\nPrefer core-owned surfaces:\n\n- `set_context_snapshot_provider(...)` for post-tool scene/document context.\n- `register_adapter_instructions(...)` for adapter instruction resources.\n- `register_project_tools(...)` for resumable project state.\n- `server.resources()` or a public resource binder when available.\n- `plugin_manifest(...)` for machine-readable install metadata.\n\nIf a needed adapter context requires private inner-server access, keep the shim\nin one adapter-local module and open a core issue.\n\n## 5. Decide What Belongs in Core\n\nEscalate to core when more than one adapter would need the same helper:\n\n- skill metadata lifecycle hooks;\n- host-thread readiness bits;\n- resource registration patterns;\n- sidecar/install lifecycle;\n- gateway search/describe/call response shape;\n- UI Control automation contracts;\n- file/artifact handoff;\n- diagnostics, agent trace packets, compact debug negotiation, and issue-report exports.\n\nAdapter repositories should contain host facts and host API calls. Core should\nown reusable MCP, gateway, catalog, lifecycle, and wire contracts.\n\nAdmin issue reports are public-safe by default. They should expose request\nstatus, DCC type, tool family, timing, sanitized error kind, token accounting,\nredaction status, and relative debug links without raw payload previews or local\nmachine details. Full debug bundles remain a core-owned explicit raw export\n(`?mode=raw`) for reviewed local evidence only.\n\nGateway/admin token accounting has two distinct concepts. Payload token fields\n(`payload_token_usage`, `payload_token_accounting`, trace input/output tokens)\nestimate captured request/response previews and must report missing coverage\nexplicitly. Response token accounting (`token_usage`, `response_token_accounting`,\noriginal/returned/saved tokens) describes JSON/TOON compaction savings and must\nnot be used as a substitute for missing payload estimates.\n\nFile v0.19.106:references/ASYNC_RECOVERY.md\n\n## Chunked Main-Thread Jobs\n\nUse the shared chunked path when a main-affinity operation cannot finish within\none host UI tick. The adapter owns scheduling; skill code only defines bounded\nsteps:\n\n```python\nfrom dcc_mcp_core import chunked_job\n\n@chunked_job(total=100)\ndef bake_frames():\n    for frame in range(100):\n        yield lambda frame=frame: bake_one_frame(frame)\n\n# A declarative in-process tool returns this runner. HostExecutionBridge\n# detects and submits it to HostUiDispatcherBase automatically.\nreturn bake_frames()\n```\n\n- Declare `execution: async`, `affinity: main`, and\n  `job_strategy: chunked`. The bridge rejects a declared chunked tool that\n  returns a monolithic value.\n- Any operation that can exceed the caller's synchronous timeout must return a\n  job envelope. Declare `execution: async` and provide a realistic positive\n  `timeout_hint_secs`; Core routes the execution declaration through\n  `JobManager`. A timeout hint only sizes client/runtime budgets and never\n  promotes an `execution: sync` tool to an async job.\n- Yield one bounded host-API callable per step. A returned string becomes the\n  progress message.\n- `submit_chunked_runner()` advances at most one step per host pump tick, so\n  unrelated UI work can run between steps.\n- `cancel(request_id)` requests cancellation. The runner publishes\n  `cancelled` only after the next checkpoint observes it; a running native DCC\n  call or monolithic callback is not pre-empted.\n- Do not add adapter-local generator pumps, timer loops, worker threads, or a\n  second job registry.\n- Test pending cancellation, cancellation during a step, monotonic progress,\n  failure, exactly one terminal result, unrelated pump work, and at least two\n  host labels.\n\nDo not label an indivisible native call as chunked. Use\n`job_strategy: monolithic` when the host API cannot yield, or\n`job_strategy: isolated` when a process/service-owned operation can return a\ndurable job id. Isolated status must remain queryable after transport loss;\ncancellation may remain process-owner scoped when reconstructing ownership\nwould be unsafe.\n\n## Liveness and Crash Recovery\n\n- Keep registry heartbeat and HTTP readiness independent of the DCC main\n  thread. A readiness/transport timeout marks the instance `unreachable`; it\n  must not erase a row whose owner lock/PID or remote TTL is still valid.\n- Keep HTTP body limits, trusted-proxy depth, and request-rate windows on the\n  owning `GatewayState` (`GatewayIngressState`). Embedded adapters may host\n  more than one gateway in a process, so process-global lazy counters or env\n  snapshots are not a valid isolation boundary.\n- Keep backend retry policy and circuit observations on the same owning\n  `GatewayState` through `GatewayResilienceState`. Pass that state through\n  backend discovery and dispatch calls; never use a process-global circuit\n  table, because one embedded gateway must not open another gateway's backend.\n- Pass the complete `McpHttpConfig.features` snapshot into HTTP runtime state\n  with `ServerStateBuilder::with_features`. Do not copy capability booleans\n  into loose `ServerState` fields; config and runtime routing must read the\n  same `FeatureFlags` source.\n- In Rust async gateway/adapter code, share `Arc<FileRegistry>` directly and\n  call its `*_async` methods. `FileRegistry` is already internally synchronized;\n  an outer `RwLock` adds no safety and holding an async guard across its\n  flock/fsync transaction blocks the runtime.\n- Treat owner lock/PID death or remote TTL expiry as crash evidence. After a\n  crash, the adapter cannot reconnect until the DCC or sidecar starts again.\n- Preserve stable `dcc_type`, scene/project metadata, and adapter identity so\n  agents can rediscover a replacement instance. Never reuse an old tool slug\n  or direct MCP URL after the instance id changes.\n- Enable core job persistence. On restart, in-flight core jobs become\n  `interrupted` and remain queryable through the replacement instance's\n  `jobs_get_status`; adapter-owned isolated jobs need their own durable status\n  tool when they outlive the request transport. If the worker can outlive the\n  DCC/sidecar process, that status tool must be owned by the worker/service or\n  another independently live control process; gateway restart alone cannot\n  recreate an API whose owner exited.\n- A bounded SQLite shutdown may return before an in-flight statement has\n  quiesced. Core closes the old handle immediately but retains its physical\n  ownership lease until every admitted operation exits; do not start a\n  replacement owner until acquisition succeeds. Never bypass the lease or\n  reuse a second path alias to the same database.\n- Read `job_persistence` from the server `/health` payload before claiming\n  durable job history. `degraded` means recent writes failed; `disabled` means\n  the manager latched repeated failures and is serving jobs from memory only.\n  `last_error_kind` is a stable category (`readonly`, `wal`, `busy`,\n  `disk_full`, `decode`, `feature_disabled`, `retention_prune_failed`,\n  `server_shutdown`, or `backend`) for diagnostics.\n  Do not expose backend messages or filesystem paths from that status.\n  Gateway `/admin/api/health` and `/v1/debug/health` aggregate the same\n  payload-safe state per registered backend; `unavailable` means the backend\n  did not answer the bounded admin read.\n  A `retention_prune_failed` latch recovers only after a real backend prune\n  succeeds. An empty cleanup is a no-op and must leave that health state\n  disabled because it did not verify storage recovery.\n  `job_retention_hours` is opt-in startup pruning of terminal rows only;\n  leave it unset when retention ownership is not established.\n- Make every adapter-owned launch return its durable `job_id` and one canonical\n  status (`pending`, `running`, `completed`, `failed`, `cancelled`, or\n  `interrupted`). Declare its status tool in `next-tools.on-success`. Automatic\n  CLI waiting is allowed only when that poller is `execution: sync`, marks both\n  `read_only_hint` and `idempotent_hint` true, and declares a string `job_id` as\n  its only required input. Every other input must be optional and safe when\n  omitted. The poller must query exactly that ID and return authoritative progress; an\n  unknown ID is an explicit error, never permission to mint a replacement job.\n\nFile v0.19.106:references/CORE_ESCALATION_CHECKLIST.md\n\n# Core Escalation Checklist\n\nUse this before adding adapter-local framework code. If the answer is \"yes\" for\ntwo or more adapters, prefer a core issue/RFC.\n\n## Escalate to Core\n\nOpen a core issue when the adapter needs:\n\n- a lifecycle hook around skill discovery, skill load, unload, group activation,\n  resource subscription, client initialize, or tool dispatch;\n- a typed skill object transform that must apply to programmatic, MCP, REST, and\n  gateway load paths;\n- a public `DccServerBase` wrapper over a private inner server API;\n- a reusable resource/prompt/project registration pattern;\n- a readiness bit or health check shared by host dispatchers;\n- a gateway search/describe/call response field;\n- install, uninstall, or sidecar lifecycle behavior;\n- cross-DCC UI Control automation contracts;\n- common artefact/file handoff and retention behavior;\n- policy, audit, telemetry, or debug bundle fields.\n\nBefore adding a protocol DTO, check\n[`ADR-027`](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/adr/027-protocol-type-ownership.md). Adapters and\ngateway applications consume the canonical core type directly, re-export it\nfor compatibility, or use an explicit conversion when their invariants differ;\nthey do not copy generic JSON-RPC, MCP, wire, or transport fields locally.\n\n## Keep Local to the Adapter\n\nKeep code adapter-local when it is only:\n\n- the host's import path, version query, or startup hook;\n- the exact host API call, such as `bpy.ops`, `pymxs.runtime`, or Unreal editor APIs;\n- a DCC-specific menu, shelf, plugin, or bootstrap script;\n- domain tool behavior that belongs to one DCC skill package;\n- a studio-specific deployment policy.\n\n## Current Core Requests From Adapter Review\n\n- [RFC: add adapter skill-load transform hooks](https://github.com/dcc-mcp/dcc-mcp-core/issues/1204): adapters need a core-owned hook so metadata transforms apply consistently to programmatic `load_skill`, MCP `load_skill`, REST `/v1/load_skill`, and gateway-mediated loads.\n- [RFC: expose public DccServerBase resource registration surface](https://github.com/dcc-mcp/dcc-mcp-core/issues/1205): adapters need a public resource handle/helper instead of private inner-server access.\n- [RFC: add reusable adapter readiness binder](https://github.com/dcc-mcp/dcc-mcp-core/issues/1206): embedded adapters need a shared readiness binder for process, dispatcher, host-execution, main-thread, and DCC-ready state.\n\n## Issue Template\n\n```markdown\n## Problem\n\nDescribe the adapter-local code that should not be repeated in every DCC repo.\n\n## Requested Core Surface\n\n- API name or shape.\n- Which load/call/resource/readiness paths it must cover.\n- Expected error and observability behavior.\n\n## Acceptance Criteria\n\n- At least one Python adapter test.\n- At least one MCP or REST path test when the behavior crosses HTTP.\n- Backward compatibility notes for existing adapters.\n```\n\nPublic issue text must be portable. Do not include local paths, private\nhostnames, machine-specific logs, or source-attribution markers.\n\nFile v0.19.106:references/FAILURE_ROUTING.md\n\n## Failure Analysis and Bug Routing\n\nReproduce through `dcc-mcp` and keep one gateway session id. Run\n`dcc-mcp-cli doctor`, then `dcc-mcp-cli stats --status failure --session-id\n<session-id>`; preserve the failed call's `request_id`, trace/job ids, adapter\nversion, DCC version, readiness fields, and the smallest safe reproduction.\nUse `/v1/debug/issue-reports/<request_id>` for the public-safe issue body and\nreview any `?mode=raw` export locally before sharing it.\nThe bundled error report binds persisted-job diagnostics to the exact current\ninstance key. If that database is absent, report persistence as unavailable;\nnever glob a sibling instance or fall back to another process's database.\nIt likewise binds rolling-log diagnostics to the current DCC process PID; if\nthat exact log is absent, report logging as unavailable instead of selecting a\nsame-DCC sibling log.\n\nReport adapter-owned dispatch, host-thread, readiness, packaging, or install\nbugs in the adapter repository. Escalate shared CLI, gateway, protocol, or core\ncontract failures to `dcc-mcp-core`. Tool schema/script/workflow defects belong\nto the owning Skill and `dcc-mcp-skills-creator`. Record runtime feedback with\nthe gateway-owned `dcc-mcp-cli feedback` command so the report remains possible\nafter an adapter or DCC process exits; include the last known instance,\nrequest, and job ids. Instance-level `dcc_feedback__report` is the live-adapter\nFinding v1 entry point. Core must register it so runtime DCC/adapter/core/host\nversions, OS, instance id, fingerprint, and conservative redaction status are\nauto-filled; adapters must not accept agent claims for those fields or add an\nadapter-specific action/local-success fallback. Open an external issue only\nwith user authorization.\n\nCore persists accepted adapter reports under the shared registry and exposes\nthem through `dcc-mcp-cli feedback list|export` / `GET /admin/api/feedback`.\nAdapters must use `DccServerBase`'s instance-owned `FeedbackStore`; do not add a\nsecond adapter-local log, aggregation endpoint, or delete-then-copy rotation.\nThe gateway query is bounded, deduplicates by feedback id, and fails explicitly\nwhen filesystem reads or scan limits prevent a complete result.\n\nFile v0.19.106:references/HOST_PATTERN_MATRIX.md\n\n# Host Pattern Matrix\n\nUse this table when choosing adapter runtime wiring for a new DCC.\n\n| DCC family | Host API | Dispatcher approach | Notes |\n|---|---|---|---|\n| Blender | `bpy` | GUI timers or background blocking dispatcher | Keep `bpy` imports lazy so discovery works outside Blender. |\n| 3ds Max | `pymxs` / MaxPlus | Main-thread dispatcher; Python entry from startup scripts or plugin bootstrap | Treat scene mutations as main-thread-only unless proven safe. |\n| Unreal | Python, C++ plugin, or remote control | Prefer an editor plugin bridge; use Python only where deployed | Long operations should become async jobs with progress/cancellation. |\n| ZBrush | ZScript, GoZ, HTTP/IPC helper | External bridge; no embedded Python assumption | Keep bridge commands typed and bounded; avoid generic remote execution. |\n| Houdini | `hou` | Event-loop callback or headless hython dispatcher | Node graph writes are main-thread-sensitive. |\n| Maya | `maya.cmds` / OpenMaya | UI dispatcher in GUI; standalone serialized dispatcher in mayapy | Do not special-case Maya patterns into core without parameterizing host identity. |\n| Photoshop / Adobe | UXP/CEP/ExtendScript | External bridge or UI Control contract | Use structured bridge calls; do not depend on a Python-in-host runtime. |\n\nCore main-thread routing carries typed Rust results through the in-process\nexecutor. Adapters should submit through `DccDispatcher` / the core executor\nseam and must not add a JSON encode/decode envelope between same-process\nqueues. JSON remains a transport boundary only (HTTP, MCP, IPC, or host RPC).\n| Custom studio tool | Python, socket, HTTP, or CLI | Start with the least-powerful bridge that can satisfy typed tools | Document auth, scope, and shutdown behavior up front. |\n\n## Host API Rules\n\n- Import host modules inside callables or skill script entry points, never at\n  package import time.\n- Mark scene-touching tools `affinity: main`.\n- Implement REST `ToolInvoker` ports asynchronously. Core awaits host dispatch\n  directly and carries the execution context in the routed request; adapters\n  must not create a helper OS thread or a second Tokio runtime per call.\n- Use `affinity: any` only for pure file, validation, serialization, or metadata\n  operations.\n- If a tool can exceed two seconds, declare `execution: async` and a realistic\n  `timeout_hint_secs`.\n- Long host loops must check core cancellation between short chunks. Rust\n  handlers use `current_dispatch_job_context()`; metadata-driven Python skills\n  use `current_job_id()` because reserved `_meta` keys are not forwarded to\n  `main()`. Use `check_dcc_cancelled()` in Python and\n  `DispatchJobContext::is_cancelled()` in Rust. Never trust or mint a\n  client-supplied job id.\n- Interactive Python hosts should use `@chunked_job` and\n  `HostUiDispatcherBase.submit_chunked_runner()` so the shared pump executes at\n  most one bounded step per tick. Do not add an adapter-local generator pump.\n- The built-in propagation contract covers in-process Rust/Python handlers over\n  MCP and REST. Subprocess, native IPC, and remote bridge adapters must forward\n  both the server-owned job id and cancellation signal explicitly, then prove\n  that wiring in an adapter test.\n- Cancellation requests skip queued work and cooperatively stop running chunks\n  when the execution lane acknowledges the next checkpoint. They\n  cannot safely interrupt a DCC-native API call or an uncooperative hot loop\n  already executing on the host thread; use typed, bounded operations and\n  return control to the pump between chunks.\n- Every bridge path must normalize arguments and return the canonical domain\n  result envelope: `error` is a string code and structured details belong under\n  namespaced `_meta` entries. `HostExecutionBridge` and in-process dispatchers\n  must not return a JSON-RPC-style error object in the domain `error` field.\n  Keep outer host-RPC `{result}` / `{error}` transport envelopes separate.\n\n## Dispatcher Smoke Tests\n\nEach adapter should have at least one smoke that proves:\n\n- the server starts without a GUI import at discovery time;\n- a main-affinity tool runs through the host dispatcher, not the HTTP worker;\n- a pure `any` tool can run without blocking the host UI;\n- cancellation or timeout produces a structured error;\n- gateway REST or direct MCP can search, load, describe, and call one typed tool.\n\nFile v0.19.106:references/INTEGRATION_EXAMPLES.md\n\n## Example: New Nuke Adapter\n\nWhen asked to create a Nuke MCP adapter, start by mapping the host lifecycle:\nhow Python is loaded, how the UI/main thread must be entered, what headless\nmode is available, how plugins are installed, and which operations should be\nbundled as default skills. Then scaffold the adapter around core primitives:\n\n- `DccServerBase` for MCP/HTTP and skill catalog behavior.\n- `DccServerOptions.from_env(\"NUKE\")` or an adapter-specific equivalent for env-driven configuration.\n- `HostExecutionBridge` plus a Nuke dispatcher for all Nuke API calls.\n- Core project, readiness, resource, diagnostics, and gateway helpers before adapter-local glue.\n- `dcc-mcp-skills-creator` for the first `nuke-*` skill packages.\n\n## Example: Private Non-DCC Service\n\nWhen asked to expose an internal asset, render-farm, review, or production\nservice, stay in the supplied private project and start with\n[`examples/remote-server`](https://github.com/dcc-mcp/dcc-mcp-core/tree/main/examples/remote-server). It is a standalone\nservice despite the historical directory name: it binds to loopback for local\ndevelopment, discovers a bundled example Skill, and needs no DCC process or GitHub\nrepository.\n\n- Use a stable custom identifier such as `studio-assets`; do not pretend it is\n  Maya or another cataloged DCC.\n- Pass `instance_type=\"standalone\"`, leave `dcc_pid` unset, and use inline\n  execution unless a real external host boundary exists.\n- Validate the Skill, start the service, then exercise `tools/list`,\n  `tools/call`, resources, and errors with the official open-source MCP\n  Inspector before testing gateway discovery.\n- Keep development on loopback. Intranet exposure requires operator-owned\n  TLS, authentication, firewall policy, secret storage, and audit controls.\n- Package through the owner's existing wheel, archive, container, Rez, or\n  private registry workflow. Do not create or publish a public repository\n  unless the user explicitly requests it.\n\n## Cross-DCC Asset Sync\n\nWhen an adapter publishes an evolving file to another local or remote DCC, use\nCore's `AssetSyncRevision` and `FileAssetSyncStore` contract. Keep absolute\npaths process-local: public tools accept a relative source name, while both the\nsource root and consumer destination root come from operator configuration.\nValidate format and size before publishing, pass `expected_head_revision` for\noptimistic conflict detection, and materialize only beneath the consumer-owned\nroot. The adapter owns its native import, canvas, refresh, or watch behavior;\nCore owns only the path-free revision manifest, content-addressed object, and\nconflict/materialization rules. See `docs/guide/asset-sync.md` and ADR-021.\n\nFile v0.19.106:references/INTERNAL_SERVICE_WORKFLOW.md\n\n# Internal Standalone Service Workflow\n\nUse this path when the target is a private API, command-line service, asset\ndatabase, render farm, review system, or another non-DCC system. The source may\nlive in a local folder, intranet monorepo, Perforce workspace, or private Git\nserver. GitHub and the public DCC catalog are optional delivery choices, not\nprerequisites.\n\n## 1. Inspect Before Scaffolding\n\nRead the supplied project and reuse its language, package manager, service\nentry point, authentication, tests, and deployment path. Create a new project\nonly when no owning codebase exists. Do not add an adapter bridge when typed\ntools can call an existing library or bounded HTTP/CLI client directly.\n\nChoose one boundary:\n\n| Need | Build |\n|---|---|\n| Expose an existing private service | Standalone `DccServerBase` composition root plus typed Skills |\n| Add tools to an existing DCC-MCP runtime | A Skill package with `dcc-mcp-skills-creator` |\n| Control a GUI or host-thread-only API | A DCC adapter with `HostExecutionBridge` |\n\n## 2. Start With the Standalone Runtime\n\nUse a stable custom service id that describes ownership, such as\n`studio-assets`. Do not reuse a DCC name to bypass routing.\n\n```python\nfrom pathlib import Path\n\nfrom dcc_mcp_core import DccServerBase, DccServerOptions\n\nskills_dir = Path(__file__).parent / \"skills\"\noptions = DccServerOptions.from_env(\n    \"studio-assets\",\n    skills_dir,\n    server_name=\"studio-assets-mcp\",\n    instance_type=\"standalone\",\n)\nserver = DccServerBase(options)\nserver.register_builtin_actions(include_bundled=False)\nhandle = server.start()\nprint(handle.mcp_url())\n```\n\nLeave `dcc_pid` unset. `instance_type=\"standalone\"` describes the service\nlifetime; it does not mean `standalone_main_thread=True`. Keep default inline\nexecution for ordinary library, file, and network operations. Add a dispatcher\nor bridge only when a real thread/process boundary requires one.\n\nThe complete runnable example is\n[`examples/remote-server`](../../../examples/remote-server). Its historical\ndirectory name is retained for stable links, but its default is a loopback,\nstandalone internal service.\n\n## 3. Put Business Operations in Typed Skills\n\nLoad `dcc-mcp-skills-creator` and create one small Skill around a user workflow,\nnot one tool per private API endpoint. Every tool must have explicit input and\noutput schemas, safety annotations, bounded timeouts, and actionable errors.\nKeep credentials in the owner's secret store or process environment; never put\nthem in `SKILL.md`, `tools.yaml`, examples, logs, or result payloads.\n\nValidate before starting the service:\n\n```bash\ndcc-mcp-cli lint skills\n```\n\nFor hermetic tests, set `DCC_MCP_DISABLE_DEFAULT_SKILL_PATHS=1` so operator\nSkill directories cannot change discovery results.\n\nWhen the owner needs a reproducible development environment, prefer the open\nDevelopment Container specification and its open-source CLI over a bespoke\nsandbox. Reuse an existing `.devcontainer/devcontainer.json`; the runnable\nexample includes one under `examples/remote-server`. Keep credentials outside\nthe image and do not mount a host container socket unless the workflow truly\nneeds nested container control.\n\n## 4. Play and Debug Locally\n\nStart on loopback and print the resolved MCP URL. Then run the official\nopen-source [MCP Inspector](https://github.com/modelcontextprotocol/inspector):\n\n```bash\nnpx @modelcontextprotocol/inspector@latest\n```\n\nConnect with Streamable HTTP to the printed `/mcp` URL. Verify this ladder in\norder:\n\n1. `tools/list` exposes only discovery/control tools before the Skill loads.\n2. List or search confirms the owning Skill and its exact slug.\n3. Load the Skill and inspect its schema.\n4. Call one read-only tool with a valid example.\n5. Call it once with invalid input and confirm the error is safe and actionable.\n6. Stop the service and confirm its registry row disappears.\n\nUse `dcc-mcp-cli list`, `load-skill`, `describe`, and `call --wait` as\nthe agent smoke once the local service is registered. Keep the returned slug\nand `request_id`; do not guess names or retry before diagnosis.\n\nFor a hosted multi-user teaching portal, Educates is the open-source upgrade\npath: it provides per-user isolated sessions, Markdown instructions, browser\nterminals, and an embedded editor. Treat its Kubernetes, ingress, identity,\nresource quota, image registry, and session-cleanup requirements as an\noperator-owned deployment project. A local Dev Container remains the default\nuntil that operational need exists.\n\n## 5. Expose and Deliver Privately\n\nLoopback is the development default. Before binding to an intranet interface,\nrequire the operator-owned security boundary: TLS termination, authentication,\norigin/network allow-lists, secret management, audit retention, and shutdown\nownership. Never expose the Inspector proxy to an untrusted network.\n\nUse the existing internal delivery path: wheel, signed archive, container, Rez\npackage, shared deployment system, or private package registry. A studio-owned\n`DCC_MCP_CATALOG_PATH` is useful only when operators need catalog-backed CLI\ninstall plans. Local execution and direct MCP testing do not require a public\ncatalog or GitHub repository.\n\n## Acceptance\n\n- The service starts from the owner's documented command on a clean environment.\n- One typed read-only tool succeeds through MCP Inspector and the agent path.\n- Invalid input and unavailable dependency failures are structured and redacted.\n- The service is marked `standalone`, has no fake DCC PID, and shuts down cleanly.\n- Packaging uses the owner's private delivery channel with no accidental public publication.\n\nFile v0.19.106:references/RUNTIME_INTEGRATION.md\n\n# Runtime integration\n\nUse only the contracts relevant to the integration being changed. The numbered\nitems are constraints by topic, not a required sequence for every adapter edit.\n\n- Ownership and threading: vocabulary and items 1-6.\n- Shared state, scene digest and UI binding: item 7.\n- Gateway, sidecar lifecycle and readiness: items 8-9.\n- Search, task metadata, recording and experiments: remaining items.\n\nResolve `docs/guide/` references against the matching Core source checkout if\nthose documents are not shipped in the installed plugin; do not infer their\ncontents or load the entire Core documentation tree.\n\n## Runtime Vocabulary\n\n- DCC startup hook: adapter code running inside the host at application startup; it prepares env/instance data and launches the service path without blocking the DCC UI/main thread.\n- Per-DCC service: one registered runtime row for one concrete DCC instance; Python `DccServerBase` and Rust sidecars both participate as per-DCC services.\n- Sidecar: the Rust `dcc-mcp-sidecar` child launched through the stable `dcc-mcp-server sidecar` command; it bridges host RPC to MCP/REST and exits when the watched DCC dies.\n- Gateway daemon: the one machine-wide `dcc-mcp-server gateway` process that owns routing, dynamic capability search/describe/call, and Gateway Admin.\n- Guardian: a lightweight loop inside daemon-backed services that probes gateway `/health` and re-ensures the daemon through `gateway-launch.lock`; it is not a separate process.\n- Service heartbeat: registry freshness for the service row only. Do not describe heartbeat as the gateway restart trigger.\n- Service owner: the process that owns the registry sentinel and MCP endpoint; its `pid`/sentinel prove the service itself is alive.\n- Bound DCC host: optional external process identified by `host_pid`; both owner and host must stay alive. Standalone/headless services intentionally have no bound host.\n\n## Integration contracts\n\n1. Classify the ownership boundary before creating files:\n   - Public DCC adapter: run `dcc-mcp-cli dcc-types`; improve an existing\n     adapter instead of creating a duplicate. Add a genuinely new public\n     adapter to `dcc-mcp-catalog.yml` and the compatibility matrix. A pip\n     install entry requires the released universal wheel's exact HTTPS URL,\n     catalog version, and SHA-256; omit install metadata until it is published.\n   - Private non-DCC service: work in the supplied local or intranet project,\n     keep its stable custom service id private, and do not require a GitHub\n     repository, public catalog entry, issue, or release. Use a studio-owned\n     catalog only when operators need `dcc-mcp-cli install` plans.\n   - Skill package only: switch to `dcc-mcp-skills-creator`.\n2. Classify the runtime integration:\n   - Embedded Python host: Blender, 3ds Max Python, Houdini, Maya, Nuke.\n   - External bridge host: ZBrush, Photoshop, Unity, custom tools.\n   - Game/editor host with mixed Python or C++ bridge: Unreal, Unity.\n   - Standalone internal service: no host bridge; use inline execution for\n     ordinary service/file/API tools and keep every tool typed.\n3. Read the relevant reference:\n   - [ADAPTER_WORKFLOW.md](ADAPTER_WORKFLOW.md) for the build path.\n   - [INTERNAL_SERVICE_WORKFLOW.md](INTERNAL_SERVICE_WORKFLOW.md) for a private non-DCC service with no public repository requirement.\n   - [HOST_PATTERN_MATRIX.md](HOST_PATTERN_MATRIX.md) for host-specific wiring.\n   - [CORE_ESCALATION_CHECKLIST.md](CORE_ESCALATION_CHECKLIST.md) before adding adapter-local glue.\n    - [TESTING_AND_RELEASE.md](TESTING_AND_RELEASE.md) before validating or publishing.\n    - **Python 3.7 policy**: native py37 is an LTS profile with no automatic calendar expiry. Verify the aggregate Python 3.7 gate is green and `requires-python = \">=3.7\"` is unchanged before any release. `py37-lite` fallback does NOT satisfy release gates. Removal requires an accepted superseding ADR, a major release, and at least 180 days of notice.\n    - [docs/guide/gateway.md](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/gateway.md) for gateway daemon lifecycle details.\n    - [docs/guide/adapter-install-lifecycle.md](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/adapter-install-lifecycle.md) for sidecar launch/readiness details.\n    - [docs/guide/adapter-install-sop.md](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/adapter-install-sop.md) for the adapter-owned install, status, verify, uninstall, and upgrade contract.\n    - [docs/guide/adapter-release-checklist.md](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/adapter-release-checklist.md) for release train compliance.\n    - [docs/guide/new-adapter-onboarding.md](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/new-adapter-onboarding.md) for new adapter scaffolding.\n    - [docs/guide/adapter-compatibility-matrix.md](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/adapter-compatibility-matrix.md) for the per-DCC compatibility table.\n4. Start from `DccServerBase` + `DccServerOptions.from_env(...)`.\n   Classify the runtime lifetime explicitly:\n   - Embedded adapter: the service owner is the DCC process; no separate host PID is needed.\n   - Standard sidecar: pass `watch_pid=current_dcc_pid`; core publishes the sidecar owner and bound host as separate liveness signals.\n   - Other out-of-process adapter: pass `dcc_pid=current_dcc_pid` so `McpHttpConfig.host_pid` binds discovery to the DCC lifetime.\n   - Standalone/headless service: pass `instance_type=\"standalone\"`, leave `dcc_pid` unset, and do not bind it to an optional GUI process. Runtime identity is independent from `standalone_main_thread`, which controls tool execution only.\n5. Route host API calls through `HostExecutionBridge`; do not hand-roll a second script executor. Standalone services with no host-thread boundary should keep the default inline execution path.\n   For file-backed typed `main(**params)` execution, publish mapping annotations\n   only when their keys are strings (`Dict[str, V]`). Validate the requested\n   SHA-256, derived schema, and structured params before materializing inline\n   source; an invalid request must leave no script or sidecar file behind.\n6. Keep service identity data-driven: `dcc_name`/custom service id, `server_name`, env-var prefix, skill names, and gateway metadata.\n   Leave the instance port unset so core resolves `DCC_MCP_<DCC>_PORT` or asks the OS for a free port.\n7. Use core helpers for skill discovery, `MinimalModeConfig`, project tools, resources, diagnostics, context snapshots, install lifecycle, and gateway failover before writing adapter-local wrappers. Python `DccServerBase.collect_skill_search_paths()` includes marketplace-installed skills under `~/.dcc-mcp/marketplace/<dcc>` (or `DCC_MCP_MARKETPLACE_INSTALL_ROOT/<dcc>`) when the directory exists, so adapters should not add a second marketplace path convention. Hermetic adapter tests should set `DCC_MCP_DISABLE_DEFAULT_SKILL_PATHS=1`; this excludes implicit local/platform defaults, marketplace installs, and Admin custom paths while explicit, bundled, and environment-provided skill paths remain active.\n   `DccServerBase` also owns `DiagnosticRuntimeState`; do not add adapter-level\n   recorder, sandbox, screenshot-capturer, dispatcher, server, or instance-context\n   globals. Standalone registration code may inject one state into both\n   diagnostic registration helpers.\n   It also owns `feedback_store`, `script_execution_context`, and\n   `checkpoint_store`; inject them into core helpers instead of creating\n   adapter-level feedback buffers, persistent exec namespaces, or default stores.\n   Adapters that expose `execute_python` should capability-gate cheap scene-state\n   evidence by registering one host-owned callback with\n   `register_state_digest_provider(..., context=server.script_execution_context)`.\n   The callback returns `SceneStats` or its mapping shape (`object_count`,\n   `vertex_count`, `has_mesh`, optional `extra`). Run scripts through\n   `execute_with_state_digest(...)`; its native transaction pins that exact\n   provider for both observations and returns public `SceneDigestSnapshot`\n   values. A script cannot replace the provider used by its active transaction\n   or poison the next transaction through `ScriptExecutionContext`. Pass both\n   snapshots to `ScriptExecutionResult.from_value(...)`. Core bounds and redacts\n   the payload, computes a deterministic fingerprint, and fails closed when the\n   provider is absent, raises, returns malformed data, or supplies a mismatched\n   fingerprint.\n   Digest change proves only that observed state changed; leave `verified`\n   omitted/false unless an adapter-owned postcondition verifies the claimed\n   effect. Never turn contract-test evidence into a real-host success claim.\n   The fingerprint and truncation marker detect deterministic corruption; they\n   are not authentication, authorization, or proof of host identity. Core does\n   not expose a Python secret, signing oracle, signed wire tag, or native factory\n   that turns caller-supplied bytes into authenticated evidence. The adapter\n   registers the provider before the native transaction starts, but that does\n   not establish cryptographic authenticity; semantic verification remains\n   adapter-owned. Pure-Python runtimes without that boundary fail closed with\n   `scene_digest_custody_unavailable`. Mapping\n   values beyond the bounded observation budget use a fixed sentinel, keeping\n   equivalent provider mappings deterministic without unbounded reads.\n   Core does not auto-register or advertise an `execute_python` route. Gate\n   adapter discovery and route registration on successful provider\n   registration, and expose `unavailable/provider_missing` when\n   `capture_state_digest(...)` reports no provider.\n   If the script raises `Exception` or `BaseException`, the transaction performs\n   after-state readback first. Catch `SceneDigestExecutionError` and pass its\n   `cause`, snapshots, and `readback_error` to\n   `ScriptExecutionResult.from_exception(...)`.\n   A failed after-readback after a mutating script is explicitly\n   `indeterminate=true` with `verified=false`; preserve the before snapshot and\n   never retry it as if no side effect occurred.\n   Core persists gateway-accepted feedback under\n   `<registry_dir>/feedback/<dcc>-<pid>.jsonl` with bounded rotation and\n   session-end syncing. Treat `feedback_persistence_failed` as a real degraded\n   result; never add an adapter-local success fallback.\n   - For native visual UI fallback, reuse the bundled `ui-control` skill with\n     standalone `dcc-cua` 0.4.0 or newer; do not add adapter-local capture,\n     accessibility, or raw-input wrappers. Keep stateful UI calls in one\n     long-lived adapter process so each logical session retains its persistent\n     CUA bridge and window capability. Preserve `capture_provenance` with\n     evidence. The shared CUA Host owns platform accessibility, capture,\n     banner/border/cursor markers, Escape interruption, input serialization,\n     and recording. `ui-control` remains `requires_in_process: true` with\n     `affinity: any`; register `HostExecutionBridge` before skill loading.\n   - Keep structured DCC skills, host APIs, and adapter scripts ahead of\n     `ui-control`. Agents should make an explicit, agent-directed transition into the scoped\n     `snapshot` → one `act` → `snapshot` loop only when an operation is\n     unsupported, no suitable tool exists, or semantic UI Automation cannot\n     reach the required control. Re-observe after every action.\n   - For native application menu bars, route an explicit `menu_path` through\n     `ui_control__act(action=\"invoke_menu\")` when semantic click or Alt-mnemonic\n     delivery cannot prove that a Qt popup opened. Require the negotiated\n     `native_menu_path` Host capability, honor `verification_required`, and\n     re-observe the exact window before another mutation.\n   - Raw pointer and keyboard input are enabled by default only inside the\n     adapter/operator-bound DCC scope. Operators may set\n     `DCC_MCP_CUA_ALLOW_RAW_INPUT=false` to disable that runtime ceiling; the\n     adapter must not override this choice. Populate `DccServerOptions` with\n     the adapter's DCC PID and, when available, its current window title or\n     handle; Core injects that trusted scope into in-process `ui-control` calls.\n     Dedicated servers may instead use `DCC_MCP_UI_CONTROL_PROCESS_ID` or\n     `DCC_MCP_UI_CONTROL_WINDOW_HANDLE` operator overrides. Request scope may\n     only narrow that trusted PID/HWND, including a title constraint for one\n     window inside a multi-window process. Require a visible unlocked desktop\n     and matching Windows integrity level, preserve the click-through\n     border/banner/pointer feedback, and preserve\n      `user_interrupted` without automatic retry, `session_id` changes, or fallback. Once Esc stops an\n      session, only `ui_control__snapshot(resume_computer_use=true)` may request a\n      resume, and the isolated host must still obtain trusted user confirmation\n      before clearing the latch. Always call `ui_control__stop_computer_use` when\n      the workflow ends.\n      Never transition or retry through another UI/input path after a policy,\n      authorization, authentication, security, confirmation,\n      `desktop_unavailable`, or `user_interrupted` result.\n      Keep mutating UI Control tools annotated as destructive. The optional\n      `intent` may only raise the native host's independent UIA/input\n      classification. Do not introduce a model-supplied `confirmed`/`approved`\n      flag or environment bypass.\n8. Use CLI profiles (`dcc-mcp-cli gateway ...`, `list/search/describe/call`) as the user UX; treat `dcc-mcp-server` modes as runtime plumbing. Read `docs/guide/gateway.md` before changing daemon, guardian, sentinel, registry, or idle-timeout behavior.\n   Gateway discovery reuses a recent capability snapshot across adjacent\n   queries. Route adapter catalog changes through the existing\n   load/reload/unload contracts that force a refresh; never depend on every\n   search polling the full backend catalog.\n   `gateway://instances` is agent-safe by default and returns only live,\n   routable rows. Use `?include_stale=true`, `?include_dead=true`, or\n   `?view=all` only for explicit diagnosis; never route a call from those\n   expanded operator views without re-validating live readiness.\n   Once an instance is selected, reuse `gateway://instances/{instance_id}` or\n   `GET /v1/instances/{instance_id}/context` for live process/machine\n   performance, scene/documents, loaded skills, and canonical follow-up routes.\n   These reads fetch the backend context on demand, but scene freshness remains\n   adapter-owned: publish changes from a host event/main-thread callback with\n   `DccServerBase.update_gateway_metadata(...)`, and publish rich snapshots with\n   `set_scene_resource(...)`. Never claim scene awareness when the adapter has\n   not installed a publisher; `scene=null` / `no_scene_published` is explicit.\n   For agent observability, read `gateway://experiments/{experiment_id}` for\n   runs, Session DAG links, metrics, and Judge evidence; read\n   `gateway://governance` for the effective policy boundary. Keep Admin memory\n   deletion controls out of agent-readable resources.\n9. Use `dcc_mcp_core.deployment.build_sidecar_command(...)` / `launch_sidecar(...)` for library-driven sidecar startup and readiness. Installer subprocesses should use `dcc-mcp-install-lifecycle`; `dcc_mcp_core.install_lifecycle` and `python -m dcc_mcp_core.install_lifecycle` remain compatibility aliases. Read `docs/guide/adapter-install-lifecycle.md` before changing host RPC, dispatch readiness, launch stdio, `watch_pid`, or `instance_id` handling.\n   - Adapter-owned lifecycle commands must follow `docs/guide/adapter-install-sop.md`. Consume `load_install_sop_schema()` and `INSTALL_EXIT_CODES` from `dcc_mcp_core.deployment`; do not invent adapter-local result shapes or exit-code mappings.\n   - The sidecar MCP listener is dispatch-only. A py37-lite factory can expose local skill metadata, but it cannot advertise or activate declarative skills through the gateway. Require a native py37 wheel for that path, or provide a separate discovery MCP URL; never report lite `load_skill` success without an executable catalog.\n   - Wrap the outer adapter import/start block with `capture_bootstrap_errors(...)`; it is stdlib-only, records pre-MCP failures, and re-raises for the DCC's native error UI. `DccServerBase` already captures Python error logs and uncaught exceptions into the shared log plus `output://` / `events://`. Forward host-native console callbacks with `server.report_host_error(...)`; do not replace global stdout/stderr or add an adapter-local error store.\n   - For DCC-Link IPC upgrades, deploy readers that accept current version 1 and legacy version 0 before switching writers to the default versioned frame. Use `DccLinkFrame(..., version=0)` only during that compatibility window, preserve an incoming frame's version in its reply, and treat `unsupported DCC-Link protocol version` as an explicit peer-upgrade failure rather than retrying body decoding.\n   - Preserve one caller-generated request id across every execution hop. JSON-RPC responses must echo `id`; commandPort-style sidecar responses must echo top-level `request_id`; gateway REST responses must echo `X-Request-ID`. Never replace an explicit response id with the current request id, because that can disguise a stale response. Treat a missing or mismatched echo as `transport desync`, fail closed, and regression-test a slow call followed by fast calls on the same connection.\n   - Registry producers must write `ServiceEntry.schema_version` using `SERVICE_ENTRY_SCHEMA_VERSION`; rows with no field are legacy version 0. Consumers may read legacy/current rows but must reject a higher schema version without quarantining, deleting, or rewriting `services.json`. Treat that error as an explicit peer-upgrade requirement, not as corrupt JSON.\n10. Pass `instance_id` to sidecar launch helpers only when it is a real UUID for the DCC service. During early startup, omit it or pass `None`; `build_sidecar_command()` rejects cosmetic values such as `\"unknown\"` with `success=false` and `reason=\"invalid_instance_id\"` so adapters do not spawn a child that can only fail with a CLI argument error.\n    After `DccServerBase.start()`, use `server.instance_id` when adapter UI or\n    sidecar wiring needs the canonical FileRegistry identity. It is the exact\n    registered UUID and is `None` before start, after stop, or when gateway\n    registration is disabled/unavailable; never inspect private handles or\n    generate a replacement UUID.\n11. Adapter supervisors that must stop the sidecar on plugin unload should call `launch_sidecar(..., return_process=True, detached=False)` instead of reimplementing `subprocess.Popen`; keep `return_process=False` for CLI/JSON paths because the process handle is not serializable.\n12. If the adapter cannot share the gateway `FileRegistry`, register remotely through `POST /v1/instances/register`, refresh with `/heartbeat`, and deregister on shutdown; the gateway will expose the row as `source: \"http\"` in `gateway://instances` / `GET /v1/instances`, preserve `instance_short` and `mcp_url`, and route it through the same `live_instances` contract.\n    Remote registrations are untrusted input: health and capability refresh\n    only use policy-allowed, identity-matching HTTP(S) endpoints with no\n    query credentials or URL userinfo; redirects are not followed, and\n    private/link-local targets (including IPv4-mapped IPv6 literals) and DNS\n    names are rejected for periodic outbound probes. Gateway health and\n    reliability totals count only registrations accepted by that same dispatch\n    predicate; rejected registrations are reported separately and cannot\n    shadow a safe backend during DCC-type routing. Public literal IPv6\n    registrations keep an unbracketed canonical host identity; brackets belong\n    only to serialized URLs. Adapters must not copy a bracketed URL host into\n    `ServiceEntry.host` or compare raw URL text across discovery and dispatch.\n13. Keep the gateway's secondary listener on its default loopback host. Opt into LAN access only with an explicit `--remote-host 0.0.0.0` or concrete LAN IP; for same-LAN convenience discovery, build with `mdns` and pair adapter-side `--advertise-mdns` with gateway-side `--discover-mdns`. Treat mDNS as a multicast discovery hint only, keep auth/TLS policy explicit, and prefer HTTP registration or relay for routed/subnet-crossing production deployments.\n14. For NAT or routed-subnet deployments, run the tunnel agent with stable `instance_id`, `capabilities_fingerprint`, `adapter_version`, and `scene` metadata, then configure the standalone gateway with `--relay-source ADMIN_URL=PUBLIC_BASE_URL`; the gateway will expose active tunnels as `source: \"relay\"` rows with relay details in `source_meta` after probing `/v1/healthz` through `<PUBLIC_BASE_URL>/tunnel/<tunnel_id>/mcp`.\n15. Preserve gateway caller attribution when adding adapter wrappers or admin/debug routes: let legacy MCP `initialize.params.clientInfo`, MCP `_meta.agent_context`, REST `meta.agent_context`, `x-dcc-mcp-*` headers, and safe `User-Agent` fallbacks flow through core rather than logging raw prompts or local machine data.\n    The opt-in MCP 2026 path uses `server/discover` and namespaced per-request\n    metadata instead of a legacy initialize session. Consume Core's shared\n    protocol types and routing; do not copy wire envelopes into adapters or\n    Skills. Keep CLI+REST as the agent default. Before enabling a new protocol,\n    follow the [protocol compatibility gates](TESTING_AND_RELEASE.md#protocol-compatibility-gates)\n    against the exact installed artifact; a version label alone is insufficient.\n16. For lifecycle/memory/telemetry policy, use `register_lifecycle_hooks(...)`, `search_skills(..., session_id=...)`, `dispatch_session_start(...)`, `dispatch_before_tool_call(...)`, `dispatch_after_tool_call(...)`, and `dispatch_session_end(...)`; pair `MemoryRecorder(InMemoryMemoryStore()).install(hooks)` with those hooks when adapters need bounded memory summaries, failed-pattern avoidance, or session compaction. Memory injection is conservative and budgeted by default: search receives compact ranking hints, tool calls receive memory only when it matches the current `tool_name`, and session-start injection is opt-in. Use `SqliteMemoryStore()` only when longterm patterns should be durable, operator-managed in the Admin Memory tab, and included in memory hit-rate observability; disable the recorder for privacy-sensitive deployments. Open a focused core issue/RFC only when those public hooks cannot express the adapter boundary.\n17. Add one executable smoke path: unit tests for construction plus either headless DCC, mock dispatcher MCP calls, gateway REST replay, mDNS same-LAN discovery smoke, relay-source smoke, the open-source MCP Inspector for a loopback internal service, or `just idle-memory-smoke` for standalone server idle/regression checks.\n18. For gateway/admin observability, surface explicit state instead of silent zeroes: traffic panels should report disabled, unavailable, filtered, or genuine no-traffic states; skill panels should distinguish discovered, loaded, searched, selected, called, failed, and low-adoption skills; and admin-facing frames/paths should stay metadata-only or aliased unless an operator explicitly configures a private raw sink. Keep `ServiceEntry.version` as the DCC application version; use core-published `dcc_mcp_server_version` and `dcc_mcp_instance_type=gui|standalone` metadata for server regression and runtime-shape diagnostics instead of overloading DCC or adapter versions.\n19. Preserve workflow observability: adapter calls should carry request, parent, trace, session, DCC, transport, and artifact/validation metadata so the Admin workflow graph can show Intent → Discovery → Skill Load → Tool Calls → Fallbacks → Artifacts → Validation → Report without raw log reading.\n20. Preserve bounded `agent_context` task/session/turn metadata and artifact/validation-friendly tool names so Admin task outcomes can group workflows, calls, deliverables, and checks without reading raw payloads or local paths.\n21. Preserve record-replay ownership boundaries: forward server-derived\n    `agent_context.session_id`, keep UI Control logical ids connection/caller\n    scoped, and write only redacted recording projections to existing\n    `session_events`. Do not add adapter-local recorder state, a second\n    database, or a replay authority flag. Persist calls incrementally; after a\n    gateway restart, project unfinished recordings as `interrupted` without\n    restoring capture authority. Generated workflows re-resolve current tools\n    and schemas; semantic UI replay resolves fresh control ids; raw/visual\n    fallback requires exact-window calibration and drift guards.\n22. Record reproducible experiment definitions, run states, Session DAG links,\n    metrics, and judge evidence through the gateway `/v1/experiments` APIs.\n    Reuse `session_events`, workflow/recording identifiers, and artifact\n    references; do not add adapter-local experiment storage or treat judge\n    output as approval authority.\n\nFile v0.19.106:references/TESTING_AND_RELEASE.md\n\n# Testing And Release\n\nUse the smallest test that proves the adapter contract, then add one live or\nHTTP-level smoke when behavior crosses process boundaries.\n\n## Test Layers\n\n| Layer | What to prove |\n|---|---|\n| Unit | option resolution, server construction, env vars, skill path collection |\n| Dispatcher | main-affinity calls run on the host dispatcher and return envelopes |\n| Skill lifecycle | `search_skills` -> `load_skill` -> typed tool -> `unload_skill` |\n| REST/MCP | direct `/mcp` or `/v1/*` search, then the returned `next_step` |\n| Gateway | multi-instance routing, policy, compact responses, debug traces |\n| Live DCC | one host smoke that creates/queries/cleans up real scene state |\n| Packaging | wheel or plugin archive installs into the target host runtime |\n| Install SOP | `plan -> execute -> verify -> status -> uninstall`, including rollback |\n\n## Protocol Compatibility Gates\n\nProtocol selection and wire types belong to Core. Follow the\n[Core protocol router](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/adr/033-mcp-http-protocol-router.md)\nfor the exact revision under test; adapters should not duplicate its envelopes\nor enable an opt-in protocol solely because a newer model or SDK exists.\n\n| Boundary | Required evidence when changing protocol support |\n|---|---|\n| Feature flags | Test feature-on and feature-off builds; keep legacy initialize/list/call working. Advertise only implemented handlers, providers, and notification channels. |\n| Official client | Pin the SDK and lockfile. Exercise auto negotiation and explicit version selection with discovery, a nonempty tool list, and a deterministic call. Record SDK/source differences instead of silently skipping cases. |\n| Wire contracts | Cover malformed metadata/headers, request identity, argument shape, and body limits before execution; distinguish ingress errors from in-band tool failures. |\n| Artifact | Verify the PR head, CI artifact hash, and installed native module origin. Then repeat on the published wheel/sidecar with the actual feature set; source tests are not release evidence. |\n| Execution | The same declared sync/async tool must preserve result/job semantics through REST and MCP. A timeout hint is not a substitute for `execution: async`. |\n\nSuccessful protocol tests do not prove full conformance or host correctness.\nFor response-correlation issues, also test a slow call followed by uniquely\nmarked fast calls on the same real host/session, tracing IDs through every hop.\nEchoing the current request ID around a stale payload is not a fix. After a\ntimeout, query the existing job; never replay a mutation just to flush a queue.\nKeep real-host, PR-artifact, and published-release acceptance separate.\n\n## Install SOP Gate\n\nAdapter lifecycle commands must follow\n[`adapter-install-sop.md`](../../../docs/guide/adapter-install-sop.md). Import\n`load_install_sop_schema()` and `INSTALL_EXIT_CODES` from\n`dcc_mcp_core.deployment` so machine-readable results and process exit codes\nstay compatible across adapters.\n\nThe shared Core front door preserves `install --json` as a plan and emits a\npost-execution Install SOP v1 result for `install --execute --json`. Treat the\nexecution result as evidence: assert stable per-step states, rollback outcomes,\nexit/stage/error codes, executable `next_steps`, nullable receipt state, and\nverification state. Do not infer success from the earlier plan or expose raw\npaths, subprocess output, exceptions, or secrets in either output stream.\n\nUntil live-host verification is implemented for the shared executor, a local\nartifact verification step may be `ok` while `verify.directly_usable` remains\nfalse with `LIVE_DCC_VERIFICATION_REQUIRED`. Keep that boundary in adapter\ntests instead of treating package installation as live DCC readiness.\nAny planner step that still requires operator or live-host work, such as\n`register-dcc`, must be `deferred` rather than `ok`; a zero exit code does not\nturn that manual boundary into completed registration.\n\nExercise the complete `plan -> execute -> verify -> status -> uninstall`\nround trip in CI. The gate must also prove that failed replacement restores the\nprevious usable install, stale receipt paths are diagnosed precisely, and\nbootstrap failures remain visible. A mock may prove the contract when the real\nDCC cannot run in CI; retain the documented live-host validation gap.\n\n## Validation Commands\n\nPrefer repository-native commands. For Python projects, prefer `vx uv` when it\nis available in the environment, then fall back to direct Python only when the\nwrapper is unavailable or hides behavior you need to inspect.\n\nTypical gates:\n\n```bash\npython -m ruff check src tests\npython -m ruff format --check src tests\npython -m pytest\n```\n\nFor Rust/PyO3 core changes, run the workspace's `just` or `cargo` gates that\nmatch the touched crates.\n\nFor gateway discovery performance, use deterministic tests or Criterion as the\nregression gate. If a regression needs local diagnosis, build\n`dcc-mcp-server` with `--no-default-features --features gateway-daemon,tracy`\nand follow the [local Tracy workflow](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/guide/observability.md#6-local-tracy-profiling).\nDo not wrap async work across `.await` in...","readmeExcerpt":"Skill: DCC-MCP Creator Owner: loonghao Summary: Create and modernize DCC-MCP adapters Tags: latest:0.19.107 Version history: v0.19.107 | 2026-09-29T15:26:49.044Z | auto - Updated version to 0.19.107. - Documentation updates in SKILL.md and reference files. - Removed skill-card.md for cleanup. - No changes to core functionality or implementation boundaries. v0.19.106 | 2026-09-14T07:38:20.222Z | auto - Version bump: U","codeSnippets":[],"executableExamples":[{"language":"python","snippet":"from pathlib import Path\n\nfrom dcc_mcp_core import DccServerBase, DccServerOptions, HostExecutionBridge\n\n\nclass MyDccServer(DccServerBase):\n    def __init__(self, port: int | None = None, dispatcher=None, **kwargs):\n        bridge = HostExecutionBridge(dispatcher=dispatcher) if dispatcher else None\n        options = DccServerOptions.from_env(\n            \"mydcc\",\n            Path(__file__).parent / \"skills\",\n            port=port,\n            execution_bridge=bridge,\n            **kwargs,\n        )\n        super().__init__(options=options)\n\n    def _version_string(self) -> str:\n        return \"unknown\""},{"language":"python","snippet":"from dcc_mcp_core import MinimalModeConfig\n\nminimal = MinimalModeConfig(\n    skills=(\"mydcc-scripting\", \"mydcc-scene\"),\n    deactivate_groups={\"mydcc-scene\": (\"heavy\",)},\n    env_var_minimal=\"DCC_MCP_MYDCC_MINIMAL\",\n    env_var_default_tools=\"DCC_MCP_MYDCC_DEFAULT_TOOLS\",\n)\nserver.register_builtin_actions(minimal_mode=minimal)"},{"language":"python","snippet":"from dcc_mcp_core import chunked_job\n\n@chunked_job(total=100)\ndef bake_frames():\n    for frame in range(100):\n        yield lambda frame=frame: bake_one_frame(frame)\n\n# A declarative in-process tool returns this runner. HostExecutionBridge\n# detects and submits it to HostUiDispatcherBase automatically.\nreturn bake_frames()"},{"language":"markdown","snippet":"## Problem\n\nDescribe the adapter-local code that should not be repeated in every DCC repo.\n\n## Requested Core Surface\n\n- API name or shape.\n- Which load/call/resource/readiness paths it must cover.\n- Expected error and observability behavior.\n\n## Acceptance Criteria\n\n- At least one Python adapter test.\n- At least one MCP or REST path test when the behavior crosses HTTP.\n- Backward compatibility notes for existing adapters."},{"language":"python","snippet":"from pathlib import Path\n\nfrom dcc_mcp_core import DccServerBase, DccServerOptions\n\nskills_dir = Path(__file__).parent / \"skills\"\noptions = DccServerOptions.from_env(\n    \"studio-assets\",\n    skills_dir,\n    server_name=\"studio-assets-mcp\",\n    instance_type=\"standalone\",\n)\nserver = DccServerBase(options)\nserver.register_builtin_actions(include_bundled=False)\nhandle = server.start()\nprint(handle.mcp_url())"},{"language":"bash","snippet":"dcc-mcp-cli lint skills"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: dcc-mcp-creator\ndescription: >-\n  Build or modernize DCC-MCP adapters and standalone studio MCP services. For individual tool skill packages, use dcc-mcp-skills-creator.\nlicense: MIT-0\nallowed-tools: Bash Read Write Edit\nmetadata:\n  dcc-mcp:\n    dcc: python\n    layer: infrastructure\n    compatibility: \"dcc-mcp-core 0.17+, Python 3.7+\"\n    version: \"0.19.107\"\n    search-hint: >-\n      create DCC MCP adapter, Nuke MCP, DccServerBase, HostExecutionBridge,\n      dispatcher, readiness, resources, gateway, Blender, 3ds Max, Unreal,\n      ZBrush, Houdini, Maya, standalone internal MCP service, private intranet,\n      non-DCC server, chunked main-thread jobs, cooperative cancellation\n    tags: \"adapter-development, internal-mcp-service, standalone, host-runtime, dispatcher, gateway, nuke, blender, 3dsmax, unreal, zbrush\"\n    skill-reference-docs:\n      - \"references/*.md\"\n  openclaw:\n    homepage: https://github.com/dcc-mcp/dcc-mcp-agent-plugins/blob/main/plugins/dcc-mcp/skills/dcc-mcp-creator/SKILL.md\n---\n\n# DCC-MCP Creator\n\nImplement the requested adapter or service within its owner's project. A private\nservice needs no public repository, catalog entry, issue or release. For operating\nan existing app use `dcc-mcp`; for individual tool packages use `dcc-mcp-skills-creator`.\nAn already-loaded skill needs no installation or new agent turn.\n\n## Implementation boundaries\n\nUse `DccServerBase` and `DccServerOptions.from_env(...)`, with host API calls\nthrough `HostExecutionBridge`. Embedded, sidecar and standalone services have\ndifferent owner/host lifetimes; resolve that contract before wiring the runtime.\nReuse Core's public lifecycle, discovery and state owners rather than parallel\nadapter implementations. Keep identity and host configuration data-driven.\n\nApplication UI uses project-owned `dcc-cua` / `ui-control`. Before observation\nor input report `provider=dcc-cua runtime=<version> pid=<exact-pid> hwnd=<exact-native-hwnd>`.\nMissing binding blocks actions. Read the bundled `dcc-cua` skill for UI work;\nnever fall back to generic Computer Use without the user's explicit change of provider.\n\n## Choose relevant guidance\n\n| Work | Read |\n|---|---|\n| New or modernized public adapter | [Adapter workflow](references/ADAPTER_WORKFLOW.md), [host patterns](references/HOST_PATTERN_MATRIX.md) |\n| Private standalone service | [Internal service workflow](references/INTERNAL_SERVICE_WORKFLOW.md) |\n| Server ownership, host dispatch, state digest, UI integration, gateway or sidecar wiring | [Runtime integration](references/RUNTIME_INTEGRATION.md); consult its relevant numbered contracts |\n| Proposed adapter-local workaround for shared behavior | [Core escalation](references/CORE_ESCALATION_CHECKLIST.md) |\n| Async/main-thread jobs, cancellation or reconnect | [Async recovery](references/ASYNC_RECOVERY.md) |\n| Runtime failure or issue ownership | [Failure routing](references/FAILURE_ROUTING.md) |\n| Nuke/standalone examples or cross-DCC file synchronization | [Integ"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn79keq1bp4t91s48e3x1fk3jn82w8hf\",\n  \"slug\": \"dcc-mcp-creator\",\n  \"version\": \"0.19.107\",\n  \"publishedAt\": 1790695609044\n}"},{"path":"references/ADAPTER_WORKFLOW.md","content":"# Adapter And Service Workflow\n\nUse this reference to build a new adapter, expose an internal standalone\nservice, or simplify an existing integration.\n\n## 1. Choose the Runtime Shape\n\nUse the smallest shape that can honestly run the host API:\n\n| Host shape | Typical DCCs | Recommended path |\n|---|---|---|\n| Embedded Python, GUI | Blender, Houdini, Maya, 3ds Max Python | `DccServerBase` with `HostExecutionBridge` and a host dispatcher |\n| Embedded Python, headless | mayapy, Blender background, Houdini hython | `DccServerBase` with inline or blocking dispatcher |\n| External bridge | ZBrush, Photoshop, Unity, proprietary tools | `DccServerBase` plus IPC/WebSocket/HTTP bridge helpers |\n| Editor/game engine | Unreal, Unity | Adapter-owned plugin bridge plus typed skill tools; keep Python optional |\n| Standalone internal service | Asset/review/render APIs, private CLI tools | `DccServerBase` with `instance_type=\"standalone\"`, no DCC PID, and inline typed tools |\n\nWhen an external bridge uses the public Python `DccBridge` WebSocket server,\ndeclare `dcc-mcp-core[bridge]`; the base install intentionally does not pull in\nthe optional `websockets` transport.\n\n## 2. Build the Composition Root\n\nAdapter server modules should be composition roots, not utility bins. Keep them\nresponsible for wiring only:\n\n- Resolve options with `DccServerOptions.from_env(...)`.\n- Pass the adapter's bundled `skills/` directory.\n- Attach `HostExecutionBridge` before skill discovery.\n- Register resources, project tools, diagnostics, prompts, and adapter\n  instruction resources before `start()`.\n- Keep `start_server()` and `stop_server()` thin wrappers.\n\nMinimal skeleton:\n\n```python\nfrom pathlib import Path\n\nfrom dcc_mcp_core import DccServerBase, DccServerOptions, HostExecutionBridge\n\n\nclass MyDccServer(DccServerBase):\n    def __init__(self, port: int | None = None, dispatcher=None, **kwargs):\n        bridge = HostExecutionBridge(dispatcher=dispatcher) if dispatcher else None\n        options = DccServerOptions.from_env(\n            \"mydcc\",\n            Path(__file__).parent / \"skills\",\n            port=port,\n            execution_bridge=bridge,\n            **kwargs,\n        )\n        super().__init__(options=options)\n\n    def _version_string(self) -> str:\n        return \"unknown\"\n```\n\nKeep `port=None` as the adapter default. Core resolves an explicit argument\n(including `0`) first, then `DCC_MCP_<DCC>_PORT`, then `0` so the OS assigns a\nfree loopback port. Clients discover the bound endpoint through FileRegistry\nor the gateway; use an explicit argument or environment value only when a\nfixed direct endpoint is required.\n\nFor `HostUiDispatcherBase` subclasses, the bridge creates and attaches the\nnative HTTP main-affinity queue automatically. Keep the host timer calling the\nsubclass's `drain_queue()`; do not wire a second queue in the adapter.\n\nGuard the adapter's outer startup import with\n`capture_bootstrap_errors(dcc_name, adapter_version=..., min_core_version=...)`.\nIt records pre-"},{"path":"references/ASYNC_RECOVERY.md","content":"## Chunked Main-Thread Jobs\n\nUse the shared chunked path when a main-affinity operation cannot finish within\none host UI tick. The adapter owns scheduling; skill code only defines bounded\nsteps:\n\n```python\nfrom dcc_mcp_core import chunked_job\n\n@chunked_job(total=100)\ndef bake_frames():\n    for frame in range(100):\n        yield lambda frame=frame: bake_one_frame(frame)\n\n# A declarative in-process tool returns this runner. HostExecutionBridge\n# detects and submits it to HostUiDispatcherBase automatically.\nreturn bake_frames()\n```\n\n- Declare `execution: async`, `affinity: main`, and\n  `job_strategy: chunked`. The bridge rejects a declared chunked tool that\n  returns a monolithic value.\n- Any operation that can exceed the caller's synchronous timeout must return a\n  job envelope. Declare `execution: async` and provide a realistic positive\n  `timeout_hint_secs`; Core routes the execution declaration through\n  `JobManager`. A timeout hint only sizes client/runtime budgets and never\n  promotes an `execution: sync` tool to an async job.\n- Yield one bounded host-API callable per step. A returned string becomes the\n  progress message.\n- `submit_chunked_runner()` advances at most one step per host pump tick, so\n  unrelated UI work can run between steps.\n- `cancel(request_id)` requests cancellation. The runner publishes\n  `cancelled` only after the next checkpoint observes it; a running native DCC\n  call or monolithic callback is not pre-empted.\n- Do not add adapter-local generator pumps, timer loops, worker threads, or a\n  second job registry.\n- Test pending cancellation, cancellation during a step, monotonic progress,\n  failure, exactly one terminal result, unrelated pump work, and at least two\n  host labels.\n\nDo not label an indivisible native call as chunked. Use\n`job_strategy: monolithic` when the host API cannot yield, or\n`job_strategy: isolated` when a process/service-owned operation can return a\ndurable job id. Isolated status must remain queryable after transport loss;\ncancellation may remain process-owner scoped when reconstructing ownership\nwould be unsafe.\n\n## Liveness and Crash Recovery\n\n- Keep registry heartbeat and HTTP readiness independent of the DCC main\n  thread. A readiness/transport timeout marks the instance `unreachable`; it\n  must not erase a row whose owner lock/PID or remote TTL is still valid.\n- Keep HTTP body limits, trusted-proxy depth, and request-rate windows on the\n  owning `GatewayState` (`GatewayIngressState`). Embedded adapters may host\n  more than one gateway in a process, so process-global lazy counters or env\n  snapshots are not a valid isolation boundary.\n- Keep backend retry policy and circuit observations on the same owning\n  `GatewayState` through `GatewayResilienceState`. Pass that state through\n  backend discovery and dispatch calls; never use a process-global circuit\n  table, because one embedded gateway must not open another gateway's backend.\n- Pass the complete `McpHttpConfig.features` snapshot into HTTP runti"},{"path":"references/CORE_ESCALATION_CHECKLIST.md","content":"# Core Escalation Checklist\n\nUse this before adding adapter-local framework code. If the answer is \"yes\" for\ntwo or more adapters, prefer a core issue/RFC.\n\n## Escalate to Core\n\nOpen a core issue when the adapter needs:\n\n- a lifecycle hook around skill discovery, skill load, unload, group activation,\n  resource subscription, client initialize, or tool dispatch;\n- a typed skill object transform that must apply to programmatic, MCP, REST, and\n  gateway load paths;\n- a public `DccServerBase` wrapper over a private inner server API;\n- a reusable resource/prompt/project registration pattern;\n- a readiness bit or health check shared by host dispatchers;\n- a gateway search/describe/call response field;\n- install, uninstall, or sidecar lifecycle behavior;\n- cross-DCC UI Control automation contracts;\n- common artefact/file handoff and retention behavior;\n- policy, audit, telemetry, or debug bundle fields.\n\nBefore adding a protocol DTO, check\n[`ADR-027`](https://github.com/dcc-mcp/dcc-mcp-core/blob/main/docs/adr/027-protocol-type-ownership.md). Adapters and\ngateway applications consume the canonical core type directly, re-export it\nfor compatibility, or use an explicit conversion when their invariants differ;\nthey do not copy generic JSON-RPC, MCP, wire, or transport fields locally.\n\n## Keep Local to the Adapter\n\nKeep code adapter-local when it is only:\n\n- the host's import path, version query, or startup hook;\n- the exact host API call, such as `bpy.ops`, `pymxs.runtime`, or Unreal editor APIs;\n- a DCC-specific menu, shelf, plugin, or bootstrap script;\n- domain tool behavior that belongs to one DCC skill package;\n- a studio-specific deployment policy.\n\n## Current Core Requests From Adapter Review\n\n- [RFC: add adapter skill-load transform hooks](https://github.com/dcc-mcp/dcc-mcp-core/issues/1204): adapters need a core-owned hook so metadata transforms apply consistently to programmatic `load_skill`, MCP `load_skill`, REST `/v1/load_skill`, and gateway-mediated loads.\n- [RFC: expose public DccServerBase resource registration surface](https://github.com/dcc-mcp/dcc-mcp-core/issues/1205): adapters need a public resource handle/helper instead of private inner-server access.\n- [RFC: add reusable adapter readiness binder](https://github.com/dcc-mcp/dcc-mcp-core/issues/1206): embedded adapters need a shared readiness binder for process, dispatcher, host-execution, main-thread, and DCC-ready state.\n\n## Issue Template\n\n```markdown\n## Problem\n\nDescribe the adapter-local code that should not be repeated in every DCC repo.\n\n## Requested Core Surface\n\n- API name or shape.\n- Which load/call/resource/readiness paths it must cover.\n- Expected error and observability behavior.\n\n## Acceptance Criteria\n\n- At least one Python adapter test.\n- At least one MCP or REST path test when the behavior crosses HTTP.\n- Backward compatibility notes for existing adapters.\n```\n\nPublic issue text must be portable. Do not include local paths, private\nhostnames, machine-specific logs, or so"}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":2068,"uniquenessScore":44,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-09T03:27:04.696Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-09T03:27:04.696Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-09T16:20:07.394Z","emptyReason":null},"items":[{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-10T18:48:31.762Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}