TLA Toolbox 1.1: Your AI Assistant Can Now Work With Your Competency Frameworks (MCP), Plus RAP, xAPI and Linked Data Upgrades

[Henry Ryng]

TLA Toolbox 1.1 is live at https://tlatoolbox.com/. The new add is an MCP server, so an AI assistant you trust can read your frameworks and RAP Sheets, run evaluations against your own LRS, and draft or validate work on your behalf. You stay in control of what it can do. The Oct 4 post covered the linked data workspace.

MCP server for AI assistants​

The server is at https://tlatoolbox.com/mcp. It uses the Model Context Protocol over HTTP and signs in with OAuth 2.1 and PKCE. Assistants that support MCP discover everything they need from the standard metadata documents and register themselves, so there is no API key to copy.

Before an assistant gets access, you sign in to TLA Toolbox and see a consent page with the assistant's name, the address it returns to, and four permissions:

• tla.read (required): search and read frameworks, competencies, xAPI Profiles and your RAP Sheets.
• tla.evaluate: run a RAP evaluation for one learner against one of your saved LRS connections. This is read only: it GETs statements and never posts them.
• tla.draft: create private draft frameworks, competencies and RAP Sheets, and edit your own drafts.
• tla.validate: dry runs only. Generate and check an xAPI Profile, check an SCD import (JSON-LD or CSV) without importing it, and validate a framework's linked data (JSON-LD expansion, IRI checks, triple count and a JSON-LD vs Turtle isomorphism check). Nothing is saved.

You can untick draft and validate on the consent page. Fifteen tools are available in total. No tool can publish, delete, change visibility, status or license, read someone else's private content, see LRS secrets, reach admin functions, or post xAPI statements. Draft tools reject publish and visibility fields outright. They are also rate limited, and every tool call is recorded in a per-user audit log (which tool, which item, ok or denied, never the payload).

Access tokens last an hour and are bound to the MCP endpoint. Refresh tokens rotate, and replaying an old one revokes the whole connection. Settings → Connected AI assistants lists every assistant you have approved, with its permissions and when it was last used, and lets you revoke it.

Tested end to end in production: a hosted assistant registered, I approved all four permissions, and it listed the 15 tools. It read my RAP Sheets, evaluated a simulated learner against my LRS and the evidence statement IDs it cited matched the ones stored in the LRS, and validated a private framework's linked data (valid, JSON-LD and Turtle isomorphic, nothing saved).

How to connect an AI assistant​

1. In your assistant's connector or MCP settings, add a remote MCP server with the URL https://tlatoolbox.com/mcp. Choose OAuth if it asks. Leave client ID and secret blank, because the assistant registers itself.
2. Click Connect. Your browser opens TLA Toolbox. Sign in if you are not already signed in, and you come straight back to the consent page.
3. Check the assistant name and return address, choose the permissions you want, and click Authorize. A short "Returning to…" page sends you back to the assistant.
4. Ask the assistant something like "list my RAP Sheets" or "validate the linked data for my electrical framework".
5. To disconnect, go to Settings → Connected AI assistants and click Revoke.

If something goes wrong, the error page now says which parameter was the problem (for example an unregistered return address) instead of a bare "Invalid request". Getting phone and hosted connectors working took several rounds: sign-in that returns you to consent, discovery at every well-known address clients try, lenient scope and resource handling, issuer in the response, and a consent page that Chrome's form-action rules allow when the assistant's callback redirects again.

Linked data​

• JSON-LD and Turtle now produce the same graph. Dates are written as ISO 8601 in both, and the exports were checked isomorphic with two independent RDF processors.
• Rubric levels and criteria are real RDF with stable IRIs and English-tagged text, instead of empty nodes. Rubrics are per competency, so a converter no longer copies one competency's criteria onto the rest of a framework.
• Free-text manual citations are published as dcterms:bibliographicCitation, rather than being dropped or misread as IRIs.
• Legacy labels are flagged as unvalidated, and modified dates match across representations.
• Concepts are typed in both SCD namespaces in use, so consumers of either find them.

IEEE 2881 Learning Metadata Terms (LMT)​

• The learning resource alignment dialog sets both lrmi:teaches and lrmi:assesses in one save, with an optional resource name.
• Competency pages show Taught by and Assessed by, and the same named alignments appear in concept JSON-LD and Turtle.
• The RAP editor can look up which competencies a learning resource assesses.
• Assertions issued by a RAP Sheet reference the aligned LMT assessment resource alongside the evidence.

Rubric Assertion Profiles (RAP) Sheets​

• Count ≥ N now means N distinct matching statements. Duplicate statement IDs are counted once, and AND/OR gates are enforced. In an offline replay through the evaluator, 10 simulated RAP Sheets against 10 simulated learners gave all 100 expected outcomes, including every "not enough evidence" case.
• Assertions use the learner's name from the evidence and list the IDs of the qualifying evidence statements.
• Since and Until windows use the time the LRS stored the statement, inclusive at both ends. Some LRSs filter on the statement's own timestamp instead, which made windows silently come back empty. Evaluate now applies the window itself and stops with a clear message rather than guessing if there is too much to read.
• LRS errors (HTTP status and message) are shown in Evaluate instead of a silent zero.
• The Browse actor filter accepts an email address, a mailto: IRI or a JSON Agent.

Inject: JSON Import​

• Statement IDs from your file are kept when they are valid RFC UUIDs (versions 1 to 8), and so are the source timestamps.
• A new Regenerate statement IDs toggle (off by default) mints fresh IDs when you want a second copy.
• Results are reported per chunk, and duplicates the LRS rejects are flagged as conflicts rather than failures.

xAPI Profiles generator​

• Generated profiles declare conformsTo https://w3id.org/xapi/profiles#1.0, and rule locations and selectors are $-rooted JSONPath.
• Empty concept, template and pattern arrays are left out instead of emitted empty.
• Generated profiles pass Yet Analytics' pan validator (0.5.4).

LRS connections and xAPI versions​

• Saved connections are resolved on the server. Evaluate, Browse, Import and Test Connection all use the stored secret, which fixes the case where Test Connection said "Connected" but Evaluate got 401.
• Test Connection now proves authentication, not just that the endpoint is reachable, and it shows the xAPI version in use. Saving a connection with an empty secret is refused, and the Saved badge shows when you have unsaved changes.
• Version negotiation: the app reads the LRS's /about. It sends X-Experience-API-Version: 2.0.0 when 2.0 is listed and 1.0.3 otherwise, and falls back to 1.0.3 if /about fails.

Smaller fixes​

• Framework cards show accurate competency counts. Clone and import refresh the list right away, with clear success and error messages.
• Anonymous visitors no longer trigger an auth error in the browser console.
• Corrected an IEEE 1484.20.3 reference in a framework description.

Known limits​

• The LRS I test against (Veracity) lists 2.0.0 in /about and accepts 2.0.0 requests, but answers with X-Experience-API-Version: 1.0.3 - unsure if i am doing something wrong here. So I am not claiming xAPI 2.0 LRS observation yet.
• Browse date filters pass straight through to the LRS, so on an LRS that filters by statement timestamp they follow that rule. Evaluate's windows use stored time.
• AI assistants can create and edit private drafts only. Publishing, licensing and deleting stay with you in the app.
• The MCP server supports public clients with PKCE. A client that insists on a client secret is registered as a public client.
• Draft rate limits are per server process and reset when the site redeploys.
• The linked data workspace is still alpha. It is not a triple store or SPARQL endpoint, and validation uses the application's own rules.

Feedback​

If you connect an assistant, I would like to hear which one, whether the sign-in and consent flow worked first time, and which tools you actually used or missed. RAP Sheet and linked data reports are just as welcome, especially against other LRSs, and especially if your LRS really answers in xAPI 2.0. Reply here or start a thread in this forum.