Integration · available · Last verified 2026-10-01
LMSY MCP and GPT Actions
LMSY MCP uses one master account credential and automatically managed paid project slots, with live-schema bootstrap, capability resolution, install preflight and integration feedback.
The LMSY MCP server exposes Marketplace discovery, capability resolution, module documentation, project-specific installation preflight and integration feedback. The integration workflow is:
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.
Configure one global Marketplace/master account credential in supported secret storage: raw X-LMSY-Key, Authorization: Bearer <account-credential>, or /mcp/<account-credential> for URL-only clients. This account key is not a key selecting one specific license. Never use query parameters for authentication and never put a projectCredential in the MCP URL. Treat credential-bearing URLs as secrets.
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.
Existing account-token connections use the global master account flow. Legacy direct-license keys and explicitly supplied project credentials remain compatibility inputs only, not the buyer setup contract. The user configures the master account credential once; the server resolves and uses each bound slot's projectCredential internally without exposing it as a setup requirement. Never require the user to copy or enter a projectCredential.
Marketplace account login does not unlock private AI Domain operations. Those APIs and private MCP tools still require the existing projectCredential, project binding and explicit capability grants; a paid Marketplace slot alone does not grant private capabilities. Candidate installSummary is compact, read-only context; module documentation and usage-policy lookup are optional. LMSY OS GPT uses a REST/OpenAPI bridge because GPT Actions do not consume MCP JSON-RPC directly. Consult LMSY Knowledge for public LMSY facts and policies.