Skip to main content
Glama

get_learner_progress

Read-onlyIdempotent

Retrieve a learner's progress in a published course using user ID and published course ID. Returns completion counts for that exact publication, preventing cross-domain mismatches.

Instructions

How far one learner has got in one course on one domain.

    `user_id` is the learner's Skilljar id, the same value v2's `list_students`
    returns. `published_course_id` identifies the course ON A PARTICULAR DOMAIN. A course
    published to two domains has two of them, with separate progress, and this
    returns the one asked for.

    That distinction is load-bearing. Skilljar's own by-id endpoint
    resolves by the underlying course, not the publication, and returns a DIFFERENT
    domain's record with a 200 when a course is published more than once. This tool selects
    from the learner's full list instead, so the answer always matches the id given.

    COUNTS ONLY, NOT WHICH LESSONS - the per-lesson endpoint returns 404 upstream.

    A learner not enrolled in that published course is a not-found error, and the
    message says how many enrolments they do have.

    Requires `CSA_SKILLJAR_V1_API_KEY`, a separate credential from the v2 client.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
user_idYes
published_course_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
scoreNo
course_idNo
max_scoreNo
domain_nameNo
enrolled_atNo
completed_atNo
course_titleNo
lesson_countNo
enrollment_idNo
credits_earnedNo
success_statusNo
has_certificateNo
latest_activityNo
enrollment_countNo
credit_unit_pluralNo
published_course_idYes
required_lesson_countNo
completed_lesson_countNo
completed_required_lesson_countNo
Install Server

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond readOnly/idempotent annotations, it discloses meaningful behavior: domain-specific course identity is load-bearing, results are counts only, a non-enrolled learner yields a not-found error including enrolment count, and a distinct CSA_SKILLJAR_V1_API_KEY credential is required. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is longer than average but every sentence carries operational importance: scope, ID semantics, upstream pitfall, capability limit, error behavior, and credential requirement. It is front-loaded with the core purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a subtle read operation with domain-scoped IDs, the description covers parameters, error behavior, capability boundary, and authentication. The output schema exists, so the lack of return-value detail is not a gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema descriptions are absent (0% coverage), but the description fully compensates: user_id is defined as the Skilljar id from list_students, and published_course_id is clarified as domain-specific with two publications having separate IDs and progress.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening line states exactly what is returned: how far one learner has got in one course on one domain. It distinguishes the tool from list_learner_progress by scoping to a single learner/course/domain and from per-lesson progress by stating counts only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong contextual guidance: the published_course_id is publication-scoped, the tool intentionally differs from Skilljar's by-id endpoint, and it does not provide per-lesson detail. It does not explicitly contrast with the sibling list_learner_progress or state when to choose that alternative, so it stops short of a full when/when-not matrix.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CloudSecurityAlliance/csa-skilljar'

If you have feedback or need assistance with the MCP directory API, please join our Discord server