Integration · available · Last verified 2026-10-01
Using LMSY with Replit
Use LMSY MCP to discover or resolve capabilities, preflight an install for the inspected Replit project, then adapt, test and report feedback.
Use this MCP workflow with a Replit project:
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.
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. Installed code remains in the project if the subscription is later cancelled.