Skip to main content
The local stdio and hosted OpenTrain MCP servers expose the same individualized-retraining operations as REST and the CLI. They are thin tools over the canonical LMS and Project To-do engines.

Discover capabilities first

Call opentrain_capabilities first. Inspect the LMS retraining family under agentSurfaces, including the family status and each operation’s authorized value. Then call opentrain_lms_capabilities and inspect its retraining, assessments, course, lessonContent, assets, preview, and mastery sections instead of relying on remembered enums or limits. Treat disabled, rollout_gated, or unauthorized as fail-closed results. The retraining capability block also identifies the two human checkpoints: worker-equivalent Preview and the no-write assignment plan. An agent must not assign directly around either checkpoint.

Tools

  1. Use the existing LMS authoring and Native Forms tools to create or update the module.
  2. Use the existing LMS Preview tools to inspect the real learner renderer without writing worker state.
  3. Register the published module if it is not already in the skill-gap registry.
  4. Create a case for one contract ID.
  5. If needed, patch the DRAFT case with opentrain_lms_retraining_update_case and its exact expected revision.
  6. Call opentrain_lms_retraining_plan_case and ask an authorized employer to review and explicitly approve the exact masked recipient, version and content hash, frozen due instant, effects, request hash, and receipt.
  7. Only after that approval, call opentrain_lms_retraining_assign_case with the exact receipt, expected revision, confirmAssign: true, and a stable idempotency key.
  8. Read the case and use existing LMS review tools to monitor or grade it.
  9. Use the canonical Project To-do RETURN operation to grant one more run when allowed.
  10. Close the case only after its outcome agrees with canonical assignment state.

Safety contract

  • Recipient resolution is exact-one and fail-closed.
  • The assignment audience is always one selected contract. Future hires are never included.
  • Planning writes nothing and consumes no attempts.
  • The plan freezes the course version, content hash, case revision, capture hash, and due instant.
  • Assignment requires an authorized employer’s explicit approval, the reviewed short-lived receipt, explicit confirmation, and a stable idempotency key. confirmAssign: true records that approved mutation; it does not let an agent self-approve.
  • Worker names are masked. Employer-only evidence does not enter the worker payload.
  • Learner and summary results never expose answer keys, correct values, prior wrong values, or per-question scores.
  • List tools are cursor-paged. Follow nextCursor until hasMore is false before claiming a complete audit.
  • Tool failures set isError: true and preserve the API status, stable error code, structured details, and request ID. Branch on those fields rather than human-readable text.

Permissions

Reads require lms:read. Mutations and the protected no-write plan require lms:write. Both the local and hosted MCP servers enforce the same organization and job authorization as REST. See the workflow guide and REST reference for the full lifecycle.