Marketplace · available · Last verified 2026-10-01
Module Intelligence and capability resolution
How MCP resolves explicit project requirements to evidence-backed module candidates, reuse, adaptation, custom remainder and a dependency-aware plan.
This article follows documentation revision 2026-10-01; the verification timestamp records documentation review, not the date a feature was introduced.
connect: Configure one global Marketplace/master account credential, initialize, and read the live tools/list schemas. Each paid project creates a free project slot under that account; project credentials are managed internally, never copied or entered by the user. Existing client tool projections may need refreshing after server updates.
analyze (lmsy.analyzeProject, lmsy.searchModules, lmsy.listCatalog): Inspect the project's files, package manifests, package manager, target workspace and existing capabilities. Catalog totals and preliminary discovery are not proof of install readiness.
resolve (lmsy.resolveCapabilities): Resolve explicit requirements against verified Module Intelligence. Results distinguish reuse, adapt, customRemainder, unknowns, composition and dependency order.
review (lmsy.getModuleDocs, lmsy.getIntegrationSupport): Review selected modules and scoped prerequisites. Documentation and integration support are available; support and getUsagePolicy are optional, not installation prerequisites.
install (lmsy.installModule): A user-confirmed install runs preflight for the project identifier, target, prerequisites, conflicts and host-adapter evidence. With the global master account credential, a new project's first successful install selects the first free paid project slot under that account and atomically binds it to projectUUID. An already-bound project reuses its existing slot; projectCredential stays internal, never copied or entered by the user. A different new project can claim another free paid slot. No free paid slot returns NO_AVAILABLE_LICENSE; it never steals or rebinds an occupied slot. Missing requirements produce structured blockers rather than a ready bundle.
verify (lmsy.reportIntegrationFeedback): The external agent adapts bundle paths to the existing MVC/workspace structure, installs dependencies, runs the app, performs a smoke test and reports integration feedback. Bundle delivery is not customer runtime verification.
Verified Module Intelligence contracts and canonical capabilities are the trusted discovery source. Text scores and legacy provides/requires remain advisory.
resolveCapabilities returns reuse/adapt guidance, customRemainder, unknowns, composition and dependency order. It is read-only and never claims a license or installs a module.
Install preflight checks substantive projectContext, target-scoped prerequisites, existing capability conflicts and host-adapter evidence. Evidence paths must belong to the inspected target package; path claims are not runtime proof.
An installation package is adapted, executed and smoke-tested by the external agent before integration success is reported.
Capability resolution is a discovery and planning result, not an install authorization or runtime test. Supply explicit projectRequirements to lmsy.resolveCapabilities. Canonical capability aliases are resolved through the published vocabulary; proposed providers are included only when an exposable catalog module has a verified, evidence-backed Module Intelligence claim. Legacy provides/requires metadata may inform advisory context but is not trusted proof of capability.
The response separates covered, partially covered and uncovered requirements; canonical capabilities already reported in the project; candidate reuse and adaptation points; and customRemainder for unmatched or unsupported work. Claim, composition and dependency evidence is returned with its associated claim or dependency. The dependency section distinguishes module prerequisites, external packages/environment variables, non-blocking BYOK advisories and unresolved needs. installOrder reports module sequence, completeness, cycles, blocked modules and capabilities not included in a capped plan. These are evidence-scoped planning details, not proof an install will succeed. Resolver projectContext does not inspect repository files or package manifests. Existing capabilities are considered only when explicitly supplied as existingCapabilities.
Before installation, separately inspect the target package and submit its project context to installModule. Preflight uses target-scoped files and declared evidence to return structured blockers for missing layout, dependencies, host adapters or conflicts; supplied host-adapter evidence is agent-reported and does not verify runtime behavior. Match uses the same verified Module Intelligence contract data, but its own selection resolver and separate hours-based reuse scoring. It does not call the same resolveCapabilities function.
The first project binding requires a canonical UUID in projectUUID. Repeat installs present the same bound ID and reuse the existing paid slot under the account; another new project may consume another free paid slot, never rebind an occupied one. This is identifier licensing, not proof of the originating host: a copied key plus the same bound ID cannot be distinguished from the original project. projectName is display-only for new bindings. Existing registered legacy bindings retain their stored identifiers and use supported mappings; never silently rewrite them or infer a UUID from a name.
Each paid project slot includes all available modules and updates for one active project identifier and one agent stream, subject to published anti-abuse limits. A global account key can manage multiple paid slots; it does not create unpaid entitlements. getUsagePolicy is optional and informational; license checks and quotas still apply. Installed code remains after cancellation.