Expose a Dynamic Registration initiation endpoint (e.g., GET /lti/register) on your tool that accepts the openid_configuration and registration_token query parameters passed by the platform.
Fetch the platform's OpenID configuration document from the openid_configuration URL using a server-side GET; extract jwks_uri, token_endpoint, and registration_endpoint from the document.
Build a JSON registration request body conforming to the 1EdTech LTI Dynamic Registration spec, including client_name, redirect_uris, initiate_login_uri, jwks_uri (your tool's JWKS), scope, and https://purl.imsglobal.org/spec/lti-tool-configuration claims.
POST the registration body to the registration_endpoint with Authorization: Bearer <registration_token>; the platform responds with a client_registration_response containing client_id and platform-specific deployment_id.
Persist the client_id, deployment_id, platform issuer, JWKS URI, and token endpoint in your tool's platform configuration store; these values are required for every subsequent LTI 1.3 launch and service call.
Display a confirmation page to the administrator and optionally trigger a test launch to verify the completed registration before closing the registration flow.
Known gotchas
The registration_token is single-use and short-lived (platform-defined, often a few minutes); the entire registration round-trip must complete within this window.
Dynamic Registration does not replace administrator review at the platform; many LMS platforms place auto-registered tools in a pending state requiring admin approval before they can launch.
Some platforms return a client_id that differs from any identifier visible in the platform admin UI; store both the client_id and deployment_id together and never reconstruct them from UI labels.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp