Skip to main content
Glama

list_visibility_overrides

Read-onlyIdempotent

List a group's course-visibility overrides, showing which published courses are allowlisted or blocklisted for that group. Use the next cursor to fetch additional pages.

Instructions

List one group's course-visibility overrides, one page at a time.

    `id` is the GROUP id. Overrides hang off the group, not off the course - which
    is the opposite of Skilljar's v1 API, where visibility hangs off the content.
    Results are one page: when has_more is true, call again with next_cursor.

    Each row says: for this group, show (`is_visible` true, an allowlist entry) or
    hide (`is_visible` false, a blocklist entry) one published course, overriding
    that course's own default.

    An unknown group is a not-found error, which is a different answer from an
    empty list. An empty list means the group exists and has no overrides.

    Rows carry `updated_at`, not `modified_at`.

    Requires the `student-groups:read` OAuth scope.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
page_sizeNo
page_cursorNo
filter_is_visibleNo
filter_published_course_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteYes
group_idYes
has_moreYes
overridesYes
next_cursorNo
Install Server

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive. The description goes beyond annotations by explaining row semantics (is_visible true = allowlist entry, false = blocklist), error semantics (unknown group vs empty list), field naming (updated_at, not modified_at), and the OAuth scope. 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?

Although long, the description is front-loaded and every clause earns its place: pagination protocol, error disambiguation, OAuth requirement, and field-name caution all prevent incorrect calls. There is no filler.

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

Completeness4/5

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

The description covers the critical disambiguation points: group-scoped overrides vs course-scoped content, pagination behavior, unknown-group vs empty-list errors, and row semantics. Because an output schema exists, not detailing return values is fine; the only residual gap is the explicit semantics of the optional filter and page_size parameters, which are left to inference.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must compensate. It clearly explains `id` as the group id and references `next_cursor` for pagination, and `is_visible` semantics are described. However, `page_size`, `page_cursor`, `filter_is_visible`, and `filter_published_course_id` are not explicitly documented; two of them are only inferable from the row-behavior explanation.

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 sentence states a specific verb and resource: 'List one group's course-visibility overrides, one page at a time.' The description further distinguishes this from the v1 API and from sibling add/remove tools, so an agent can tell exactly what this tool does.

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

Usage Guidelines5/5

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

It gives direct operational guidance: paginate with next_cursor when has_more is true, treat unknown-group as different from an empty list, and require the student-groups:read OAuth scope. It also cautions against the v1 mental model where visibility hangs off content rather than off the group.

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